Seminar/Projekt #532 Interactive Processing 2009 Interaktionsbefriff IxP

Interaktionsbegriff:

Wir wollen nun etwas theoretischer werden und zunaechst den Interaktionsbegriff etwas klarer fassen, indem wir ihn etwa gegen "Handlung" und "Kommunikation" [3] absetzen. Waehrend Interaktion ein Gegenueber erfordert, ist der Handlungsbegriff allgemeiner, die Aktivitaet dominiert und ein "Gegenueber" kann vielerlei sein, ein Objekt, der Handelnde selbst, ein Zweck. Fuer Kommunikation wiederum ist ein Gegenueber erwuenscht und zwar eines, das man als kommunizierendes Subjekt annimmt (also eventuell auch ein Teddybaer, aber im allgemeinen Menschen). Interaktion inkludiert Gerichtetheit und Reaktivitaet, zu der auch Maschinen faehig sind.

Das "Gegenueber" auf das die Interaktion gerichtet ist, ist quasi die Wirkung, die sie jeweils unmittelbar ausloest. Unmittelbarkeit etabliert typischerweise den Interaktionszusammenhang und stellt die Bedeutungseinheit her [5]. Das betrifft zunaechst triviale Schaltvorgaenge: ich betaetige den Lichtschalter - das Licht geht an, ich tippe eine Taste - der Buchstabe A wird auf dem Bildschirm dargestellt. Die verkuerzten Bedeutungseinheiten lauten: "ich drehe das Licht an" ich schreibe ein A". Diese Schaltvorgaenge sind schon weniger trivial, wenn die Wirkung konditional bedingt oder kontextabhaengig ist. Ausserdem lassen sich ja unterschiedliche Interaktionen und damit deren Wirkungen verketten, solange auf jede Wirkung mehrere Anschluss-Interaktionen moeglich sind. Wenn die Interaktion nicht ein on/off, sondern ein kontinuierlicher Datenstrom ist, dann ueberfordern wir bereits die Interaktionskomplexitaet der Interfaces der meisten Computerprogramme. Ausgenommen sind etwa Videospiele oder Flugsimulatoren: hier wird interagiert obwohl, oder weil die Wirkung mehr oder minder unbekannt ist.

Voraussetzung ist, dass das Interface eines Programms, Dienstes, Devices, Instruments, Werkzeugs, etc. einen Interaktionsspielraum derart abdeckt, dass das Repertoire an Interaktionen, die eine Wirkung/Funktion ausloesen einer gewissen Logik folgt und Interaktionen, die nichts oder Fehler bewirken, abgefangen werden. Ausserdem bieten Programme - ihrer Zweckbestimmung folgend - nur ein Subset der grundsaetzlich denkbaren Wirkungen/Funktionen an, wodurch sich Interaktionsluecken (denkbare aber wirkungslose Interaktionen) ergeben. Ausserdem scheint die Wahl des Subsets haeufig von einem Werkzeug-Konzept geleitet: um einen Nagel einzuschlagen benoetige ich einen Hammer, um ihn wieder herauszuziehen eine Zange. Das befriedigt so lange, als es sich bei den Aufgaben weitgehend um so etwas wie hineinzuschlagende oder herauszuziehende Naegel handelt [6]. Interaktions-technisch befinden wir uns auf dem Niveau von on/off-Schaltern

Interaktion als dynamische Loop

Interessant wird es wenn man, wie vorhin gesagt, mit dem "Unbekannten" interagiert. Wenn man beispielsweise einen Flugsimulator steuert, weiss man nicht immer, wie sich eine steuernde Interaktion auswirken wird. Man arbeitet also mit testweisen, geringen, kontinuierlichen Veraenderungen und achtet auf das Feedback, um gegebenenfalls in die Gegenrichtung korrigieren zu koennen (trial&error). Diese kontinuierliche Kontrolle ist typisch z.b. fuer den Werkzeuggebrauch und die Steuerung von diversen Fortbewegungungsmitteln (z.B. Schifahren). Sie hat den Vorteil, dass das Risiko eine ungwollte Wirkung zu produzieren gering ist und leicht zum Ausgangspunkt zurueckgefunden wird. In der Schleife mit dem Feedback lernt man rasch zu steuern.

Das InteraktionsFeedback ist aehnlich der Kopplung von Sensor und Aktuator in der Robotik, die es erst gewaehrleistet, dass der neue Zustand den eine Aktion hervorgerufen hat ins System zurueckgeschliffen wird, um weitergehende moegliche Zustaende zu konzipieren. Der Zustand sollte nicht aus der Steuersoftware (flag einer exekutierten Funktion) bezogen werden, sondern laufend aus den tatsaechlichen Zustaende (also ueber Sensorik) errechnet werden, da auf diese Weise eventuelle Komplikationen abgefangen, oder Funktionen in der Mitte abgebrochen werden koennen.
(siehe z.B. http://virtuallab.tu-freiberg.de/website/publicat/p2e_over.htm)

Gaengige Applikationsinterfaces bieten eher diskrete Veraenderungsschritte an, als koninuierliche. Z.b. weil kontinuierliche Steuerung schwieriger zu verstehen und zu erlernen scheint. Oder weil sie zu komplex in der Implementierung waere, etc. Und da ein Programm nicht fuer alle Moeglichlkeiten vorsorgen kann, wird ein Subset einiger grundsaetzlichen Moeglichkeiten gebildet, das fuer das Programm als umsetzbar und einigermassen konsistent/vollstaendig und fuer den Nutzer als ueberschaubar/erlernbar erachtet wird. Als Ansatz fuer die Wahl dieses Moeglichkeits-Subsets hat sich ein gewisser Pragmatismus, ein Selbstverstaendnis und ein scheinbar aus der Wirklichkeit entlehnter "Materialismus" durchgesetzt. Zumeist besitzt dieses Subset eine gewisse immunisierende Logik und wenn von Nutzern neue/modifizierte Funktionen gewuenscht werden, so folgen auch sie dieser Logik.

Artificial Intelligence (vor 30 Jahren) hatte das Problem gesehen und verschiedene Wege verfolgt dem strengen Determinismus und der Teleologie zu entgehen. Wenn sie (angeblich) gescheitert ist, dann weil sie mithilfe der AI Haemmer erzeugen wollten, bzw. weil die Kritiker ihr vorwarf keine effizienten Haemmer liefern zu koennen. Aber ich denke die AI war schon durch das Artikulieren der Fragen und durch dasExplorieren moeglicher Wegen erfolgreich und stuende auch erfolgreicher da, wenn sie sich deutlicher und ueberzeugender als Alternative zum Hammerschmieden deklariert haette.

Inwiefern unterscheidet sich das ixp-Konzept vom Werkzeug-Konzept? Wir gehen hier nicht so weit wie die AI. Wir integrieren den Werkzeug-Aspekt eines Programms mit dem kontextrelevanten Interpretationsbereich des Nutzers als verarbeitbaren Gegenstand. Wuerde der IxP-Ansatz einfach funktional implementiert, dann waeren wir wieder beim Werkzeug. Das wesentliche dabei ist die Offenheit, fuer den Nutzer zu entscheiden welche Interaktionsaspekte wie abgefangen und ausgewertet und wiederum ins System geschleift werden sollen (insofern beduerfte es einer API).

to be cont'd & refined