Wir befassen uns an der MMK üblicherweise mit Design und Ergonomie von Schnittstellen bei sogenannten "Softwareprodukten". Vorab tun wir häufig so, wie wenn uns klar wäre, was Design und Ergonomie, und sowieso was Software sein soll. An den Tagungen geht mir diese Klarheit ebenso häufig verloren - bis sie dann in den Schlussvorträgen auf erwartbare Weise aus den Hüten gezaubert wird. Ich schlage deshalb - in einer Anlehnung an BB eine kleine Verfremdung vor. Lasst uns über den Sinn einiger der uns liebsten Konzepte nachdenken, indem wir sie einmal auf etwas einfacher zu begreifende Gegenstände anwenden. Pferde und Motorräder sind dabei exemplarisch gedachte Beispiele, die beliebig durch andere Vertreter des Exemplarischen ersetzt werden können: es sollen Gegenstände sein, die wir mit den Händen so "begreifen" können, dass wir Schnittstellen- und Ergonomieprobleme "erfahren" können. Der Titel der AG kann also unter Einhaltung folgender constrains beliebig verlängert werden: Es müssen Erfahrungsverben sein, die sich auf ein Objekt beziehen, dessen Schnittstellen man mit den Händen begreifen kann.
Pferde und Motorräder greifen nach meinen Emotionen - das wissen ja auch die Marlboro-Strategen gut genug. Ich will aber gerne und seriöserweise rationalisieren, weshalb diese Gegenstände als Exemplare für Dialoge über Design und Ergonomie bestens geeignet sind. Im englischen "to ride" und im österreichischen "Reitwagen" (für Motorrad) ist eine Verwandtschaft deklariert, die in den Sachen - Tier und Maschine - überhaupt nicht gegeben erscheint, wenngleich N. Wiener seine Kybernetik, die vor allem unser lieben Computer meint, mit dem Untertitel "Kommunikation im Tier und in der Maschine" publizierte. Das Pferd ist ein zweckloses Lebewesen, das Motorrad wird zum Zwecke des Er-fahrens gebaut. Wo ich auf beidem "reite", bringe ich eine Beobachterperspektive ins Spiel, in deren Focus eine Usability - sozusagen die Reitbarkeit for fun - steht, die sich nicht um irgendwelche ursprünglichen Zwecksetzungen kümmert. Als ingeniöser Konstruktivist frage ich mich, wie ich Pferde und Motorräder konstruieren muss, damit sie mir viel Spass machen - oder seriöser, damit sie ihren von mir gesetzen Zweckoptimal erfüllen.
Ich hör(t)e Einwände: Pferde seien gar nicht konstruiert, Motorräder seien sehr simple Konstruktionen, weil sie einen engen Zweckbereiche haben. Bei Software sei alles anders, viel viel komplexer ..
Zuerst: Lässt sich anhand von einfachen bis scheinbar untauglichen Beispielen Wissen entwickeln, das auch in der komplexeren Umgebung des Ernstfalles brauchbar ist? Genau diese Frage wollen wir subjektiv empirisch untersuchen. Unsere AG wagt den Versuch, danach werden wir mehr darüber wissen, ob dieser Weg begehbar ist.
Dann: Für Konstruktivisten sind auch Pferde Konstruktionen. Pferdezüchter brauchen klare Designvorstellungen. Die Natur hat kein Tier hervorgebracht, dass ich spontan als Pferd bezeichnen würde. Naturliebende Tierfreunde vergessen ja auch gerne, dass Hunde das Resultat langer Domestizierungsprozesse sind. Im Pferd steckt eine unglaubliche Formarbeit, auch wenn solche Arbeit nicht an einem einzelnen Pferd geleistet werden kann. Und es gibt ein breite Palette von Pferdetypen, die sich an verschiedensten Usabilities orientieren. Auch wer noch nie auf einem Pferd gesessen ist, kann vielleicht einen - hinterfragbaren - Unterschied sehen zwischen einem Pferd, dass im Gespann Bier auf die Wiesen zieht und einem Pferd, wie es Omar Sharif als Araberfürst im Film Lawrence von Arabien geritten hat.
Die Usability umfasst natürlich auch das erweiterte Pferd. So gelten etwa die Steigbügel als eine der kulturell folgenreichsten Erfindung überhaupt. Steigbügel ersetzen Reitkunst. Die Steigbügel der US-Kavallerie waren bei der Ausrottung der Indianer mindestens so wichtig wie Vorderlader und Revolver, weil nur dank Steigbügel genügend rasch genügend viel Kavalleristen mobilisierbar waren. Und Ritter in Rüstungen wie Ivanhoe waren natürlich auch nur mit Steigbügeln möglich.
Motorräder sind Desingprodukte schlechthin. Keine Ausstellung im New Yorker Guggenheim war so erfolgreich, wie jene, die die Entwicklung von Motorraddesign veranschaulichte. Aber Motorräder wollen natürlich auch gefahren werden. Kaum ein technisches Produkt verlangt so viel Können vom Benutzer wie ein Motorrad. Die "Design"-aufgabe verdeutlichte B. Spiegel: "Stellen wir uns vor, wir seien in einem großen Unternehmen Mitglied eines Ausschusses, der über neue Produkte zu befinden hat. Es gäbe bis heute nur Automobile auf der Welt, aber weder Fahrräder noch Motorräder, und nun erschiene ein Erfinder und würde uns Zeichnungen und Modelle von einem merkwürdigen Einspurfahrzeug vorstellen, das nicht viel mehr ist als ein Vierzylindermotor mit zwei Rädern daran: Hubraum Kleinwagen, Leistung Mittelklassewagen, Geschwindigkeit Sportwagen, Beschleunigung Rennwagen, Gewicht eine viertel Tonne. Also eine moderne Tausender. Wir würden uns wahrscheinlich sehr rasch wieder von ihm verabschieden, und in unserem Sitzungsprotokoll für den Vorstand, in dem wir unsere Ablehnung zu begründen hätten, schrieben wir - halb bestürzt und halb belustigt über den Unverstand dieses Erfinders - ungefähr folgendes: "... verwirrend ist vor allem die außerordentlich große Zahl der Bedienungselemente. Diese muß der Fahrer buchstäblich mit Händen und Füßen und manche sogar gleichzeitig betätigen, wobei er nach Angabe des Erfinders während der Fahrt außerdem noch ununterbrochen den sogenannten Lenker mit beiden Händen bedienen muß. Wir zählten insgesamt mehr als ein Dutzend verschiedener Funktionen. Läßt man die nur gelegentlich zu betätigenden wie Zündung, Starter, Horn, Lichthupe, Blinker, Abblendschalter und so weiter unberücksichtigt, so verbleiben außer den beiden Lenkergriffen, die auch auf gerader Strecke - vor allem bei langsamerer Fahrt - wegen der erforderlichen Balance unausgesetzt betätigt werden müssen, noch fünf weitere Bedienelemente, die eine häufige bis ständige Betätigung erfordern. Dabei muß zum Beispiel allein der linke Fuß, der die Gangwahl zu übernehmen hat, mit einer Art Folgeschalter zwischen sieben Positionen (nämlich sechs Gängen und dem Leerlauf) wählen" (ganzer Artikel).
Ganz so einfach ist also die Sache mit der Konstruktion von Pferden und Motorrädern auch nicht. Die Frage, wie weit man welchen Benützern mit welchem Geinn entgegenkommen muss, lässt sich auch an solchen Beispielen gut diskutieren. Und ist nicht das die sogenannte Ergonomiefrage schlechthin?
Schliesslich: Was meinen wir mit Software? Ich schlage auch hier eine Art von Verfremdung vor, die ich allerdings lieber als Entfremdung sehe:
Der Ausdruck "Software" verweist meines Erachtens nicht auf einen Gegenstand (etwa auf ein Programm) oder gar auf ein metaphysisches Sein wie Information, sondern auf eine spezifische Eigenschaft einer bestimmten Typ von Maschine. Diese Eigenschaft besteht darin, dass die Maschine leicht in verschiedene konfrete Maschinen transformiert werden kann. Das mache ich etwa, wenn ich unter Windows per Knopfdruck von der Textverarbeitungsmaschine zu einer Buchhaltungsmaschine wechsle. Solche Maschine sind in dieser Hinsicht "soft", weil sie nicht festgelegt sind, auch wenn sie aus hartem Material bestehen. In dieser Hinsicht halbsoft ist etwa eine BlackandDecker, die veschiedene Funktionen hat, wenn man einen Bohrer oder eine Schleifscheibe einspannt. Natürlich bezeichne ich Bohrer und Schleifscheibe nicht als Halb-Software und Programme nicht als Software. Dass ein Programm keine "Software" ist, sieht man unter anderem am Aufwand, der zu leisten ist, um ein Programm zu ändern. Programme sind starre Artefakte.
Die MMK kennt solche Verfremdungen schon lange. Der alte MMKler R. Keil-Slawik etwa sagt: Programme sind auch hardware. Ich frage mich, was er mit dem "auch" ausdrücken will. Viel mehr aber frage ich mich, inwiefern es uns gelingen könnte, unsere Sicht auf Software-Ergonomie etwas aufzuweichen (unfreeze - change freeze). Deshalb schlage ich einen Dialog über reiten und motorradfahren vor.
Die Informatik ist eine Konstruktionswissenschaft (ich denke dabei natürlich an den Radikalen Konstruktivismus), viele Informatiker scheinen aber aber unter einer fatalen Wahnvorstellung zu leiden, die aus der Mathematik stammt. A. Turing und Konsorten haben die "universelle Maschine" propagiert. Universell ist aber - von der darin enthaltenen Allmachtsvorstellung einmal abgesehen - keiesfalls die Maschine, sondern allenfalls die Steuerung der Maschinen. Ich spreche genau dann von einer Maschine, wenn ich ihr einen Zweck zuordnen kann. Eine Bohrmaschine ist zum Bohren gemacht. Wer will, kann damit universell bohren, und wer will, kann sie als Briefbeschwerer oder in der Not als Hammer benützen, das ändert ihre Gegenstandsbedeutung nicht. Eine Maschine hat einen Zweck. Dass ich mit einer bestimmten Steuerung verschiedenste Maschinen steuern kann - was ja auch nur extrem abstrakt wahr ist - ändert an der Zweckbestimmung der Maschinen nichts.
Ich glaube, es wäre ziemlich blöd, ein Motorrad mit Zügeln zu steuern und einem Pferd Blinker wachsen zu lassen. Die universalisierende Redeweise "to ride" ist funktional, nicht konstruktiv gedacht. Die Konstruktionen, die ich "ride", sind ziemlich verschieden - und das gefällt mir sehr gut so. Wieso also müssen alle Maschinen, die Informatiker konstruieren, egal was sie tun, so kramphaft universell gleich aussehen? Wer würde - um im Bild zu bleiben - die Vorzüge von Motorradfahren und Reiten so vermischen, dass Konstruktionen rausschauen, mit denen man beides und auch noch vieles mehr kann.
Meine Subthese lautet: Seit F. Taylor die Produktion oder genauer die industrielle Betriebsführung verwissenschaftlichte, scheint es effizient, wenn alle Produktionsmittel gleich aussehen, weil so jede billige Arbeitskraft alles kann und durch jeden ersetzbar ist. Ergonomie und Design könnten aber auch dem konstruktivistischen Prinzip folgen, wonach die Vielfalt zu fördern ist.
Qualitätssicherung, best practise, Standards usw erhöhen kurzfristige Profite, sie reduzieren aber die Chancen der Evoution. Ob es gut werden kann, wenn alle dasselbe tun?
Einem MMK-Standard folgend würden alle, die mitmachen, das Moderationspaier "kritisieren". Aber kriitisieren lässt ja beliebigen Raum. Ich könnte mir - neben aller Kritik - gerne weitere Beispiele vorstellen. Pro Beispiel ginge es zunächst darum, die aktuelle Gestaltung zu reflektieren und die üblichen Software-Ergonomie-Fragen zu stellen. Vielleicht lassen sich so auch neue Ideen in bezug auf die Beispiele generieren. Und vielleicht zeigt sich, dass einige Fragen unsinnig sind. Solche Fragen könnten natürlich für Software immer noch sinnvoll sein, aber man müsste das nochmals begründen. Dabei müsste man Software wohl genauer charakterisieren und zeigen, inwiefern es sich um spezielle Maschinen handelt.
Insgesamt verspreche ich mir von diesem Dialog eine bewusstere Einsicht über mein Verhältnis zu Maschinen oder eben über die Verhältnisse MMK.
Ich habe unter http://www.hyperkommunikation.ch/seminare/mmk2004/index.htm eine Site für die AG geöffnet. Wenn jemand da draufschreiben will, kann er von mir die FTP-Angaben haben. Ihr könnt mir Eure Beiträge auch mailen, dann stelle ich sie auf die Seite (falls Ihr nichts dagegen habt). Ich finde das Netz eine praktische Geschichte für MMK.