Interaktionsdesign-Erklärungen für die Nachwelt

Sie lesen einen älteren Blogeintrag. Bitte beachten Sie, dass die hierin enthaltenen Informationen technologisch veraltet sein können. Dieser Text spiegelt nicht unbedingt meine aktuellen Meinungen oder Fähigkeiten wider.

Dies ist die originale deutsche Version dieses Textes. Er ist auch als englische Übersetzung verfügbar.

28. Dezember 2011

Im Sommersemester 2011 habe ich als studentische Hilfskraft die Veranstaltung Interaktionsdesign bei Prof. Oberquelle mitbetreut. In diesem Rahmen habe ich im (geschlossenen) CommSy-Raum der Veranstaltung einige Fragen schriftlich beantwortet, die den Veranstaltungsteilnehmern bei der Prüfungsvorbereitung aufkamen. Es wäre schade wenn diese Texte einfach verlorengehen, deshalb habe ich sie hier geringfügig aufpoliert und zusammenhängend wiedergegeben. Ob die Inhalte im nächsten Durchgang der Veranstaltung überhaupt noch relevant sind, das ist natürlich noch nicht in Stein gemeißelt. Trotzdem viel Vergnügen damit!

Tangible Media

Ich habe eben noch mal die MIA-Folien durchgeschaut und leider tatsächlich keinen Definitionsansatz dort gefunden. Auf S. 17 und 18 von MIA11-4.pdf gibt es Beispiele. Die Grundidee wird vermutlich durch Beispiele schon einigermaßen gut klar.

Aber was ist mit dem Begriff gemeint? Über die Bedeutung von „tangible“ – greifbar, anfassbar – kommt man schon ganz gut heran. Ein Tangible User Interface erlaubt es uns, den Computer zu steuern, indem wir physische Objekte manipulieren, mit denen wir eine sehr hohe Direktheit der Interaktion erreichen. Einfach gesagt kann Tangible Media alles sein, bei dem physische Objekte mit digitalen Repräsentationen „verbunden“ werden, so dass wir den Zustand der digitalen Welt verändern, wenn wir den Zustand der physischen Objekte verändern. Das ist allerdings immer noch relativ schwammig, deshalb erzähle ich einfach mal ein bisschen genauer…

Vorweg: Tangible Media ist kein besonders technischer Begriff. Aus technischer Sicht wird schließlich jedes Eingabegerät irgendwie physisch manipuliert und bewirkt etwas im Computersystem durch seine Sensordaten. Tangible Media gehört konzeptuell eher in die Schublade der Benutzbarkeitsforschung, Experience Design usw. und berührt neben der Technik auch Dinge wie die mentalen Modelle der Benutzer.

So etwas wie Maus und Tastatur sind Allzweck-Steuergeräte, mit denen wir viele verschiedenen Aufgaben erfüllen können. Diese Geräte werden auf ihre Grundfunktionen (Tastatur: einzelne, diskrete Tastendrücke, Maus: Bewegung in der 2D-Ebene) reduziert und von allen anderen Eigenschaften wird abstrahiert. Auf diesen Grundfunktionen bauen wiederum unsere hochkomplexen Desktop-Softwaresysteme auf. Aufgrund dieser „Kluft“ zwischen den physischen Objekten und der Nutzung würde ich Maus und Tastatur nicht als Tangible Media bezeichnen. Dieser Eindruck wird verstärkt dadurch, dass Computerbenutzer recht schnell lernen, die Maus und die Tastatur zu „vergessen“ und nur noch in virtuellen Konzepten zu denken.

Bei Tangible Media habe ich dagegen physische Objekte, die erstens eng mit der digitalen Repräsentation gekoppelt sind, so dass meine Interaktion mir „direkt“ erscheint. Dadurch, dass ich etwas bspw. anfasse und bewege, verändere ich die digitale Welt so, als hätte ich sie an der gleichen Stelle und auf die gleiche Weise angefasst und/oder bewegt. Zweitens stehen diese phyischen Objekte zusammen mit ihren digitalen Repräsentationen (meist als Einheit) in meinem mentalen Modell im Zentrum. Sie sind nicht nur Werkzeug, sondern auch Material.

Eine spannende Frage in diesem Themenfeld wäre, inwieweit Touchscreens „tangible“ sind. Die Dinger sind schön direkt und physisch, allerdings verändert man sie normalerweise nicht und mit der Material-Sicht haben sie auch nicht viel zu tun. Das wäre vielleicht eine spannende Frage, die man mal in einer Prüfung diskutieren könnte. (Disclaimer: Mit den Prüfungen von Herrn Oberquelle habe ich nichts zu tun und habe weder Einblick in noch Einfluss auf die dort gestellten Fragen.)

Ich hoffe das hilft schon mal. Bei Wikipedia gibt es ansonsten noch ein bisschen was zum Thema: Wikipedia – Tangible User Interface

L-Shape

Für Virtual-Reality-Systeme gibt es die sogenannten „Caves“. Das sind spezielle Räume, in denen die Wände, Fußboden und ggf. auch die Decke als Bildschirme genutzt werden können, so dass für eine Person ein ziemlich hoher Grad der Immersion in eine virtuelle Welt erreicht werden kann. (Meist ist darüber nämlich auch noch stereoskopische 3D-Grafik möglich.) Ein Nachteil von Caves ist, dass sie ziemlich aufwändig und teuer sind, weil die ganzen Projektoren irgendwie untergebracht werden und zusammenarbeiten müssen. Ein weiterer Nachteil ist, dass man sich in der virtuellen Welt zwar ohne Probleme rundherum drehen, aber nicht herumlaufen kann.

Bei einer L-Shape handelt es sich grob gesehen um die Light-Version einer Cave. Man lässt die Decke und drei der vier Wände weg, so dass man sich nur noch um eine Wand und den Boden kümmern muss. (Man stelle sich das räumlich vor, dann erkennt man die Form des Buchstaben „L“.) Das senkt die finanziellen Kosten enorm, verringert aber natürlich auch die Immersion. Das muss man bei der Planung solcher Systeme abwägen. In L-Shapes kann man sich dann anders als in Caves nicht mehr herumdrehen, ohne die Grenzen der Grafikdarstellung zu verlassen. Ansonsten sind L-Shapes und Caves sich funktional ziemlich ähnlich.

Allgemeines zu Modellen

Ich höre von Zeit zu Zeit ein leises Raunen, warum man sich im MCI-Bereich eigentlich mit diesen ganzen Modellen befassen soll, die alle irgendwie ähnlich und trotzdem unterschiedlich sind, und dennoch die Realität nicht vollständig abbilden. Warum machen wir uns die Mühe?

Aus wissenschaftstheoretischer Sicht sind sie eine Möglichkeit, die Realität zu beschreiben. Ein großer Teil auch unserer Arbeit als Wissenschaftler (das werdet ihr wahrscheinlich schon bei eurer Bachelorarbeit feststellen) besteht nicht nur darin, Dinge herauszufinden und zu erklären, sondern auch, Dinge kommunizierbar zu machen, über die vorher nicht gesprochen werden konnte. Wir beobachten komplexe Zusammenhänge in der realen Welt und wollen uns in der wissenschaftlichen Gemeinde darüber austauschen und damit auseinandersetzen. Damit das geht, müssen wir zunächst abstrahieren und strukturieren, was wir zu sehen glauben. Auch das PACT-Modell ist ein Versuch, bis dato unkommunizierte reale Zusammenhänge in eine Struktur zu gießen, in der sie für Außenstehende (also zunächst mal auch uns) erschließbar sind.

Nachdem man sich eine Weile mit solchen Modellen befasst hat, drängt sich manchmal die Frage auf, was man dabei eigentlich gelernt haben soll. Tatsächlich ist das PACT-Modell auch hierfür ein gutes Beispiel: Als mittelmäßig bis gut qualifizierte Informatikstudierende erzählt es uns im Grunde nichts, was wir nicht schon vorher im Prinzip irgendwie gewusst haben. Der Verdienst des Ganzen ist aber, dass wir eine gemeinsame Kommunikationsbasis haben, nachdem wir uns mit dem Modell auseinandergesetzt haben. Wir können untereinander die gleichen Begriffe verwenden, können halbwegs sicher sein dass wir ungefähr das Gleiche meinen, und – hier ist der Knackpunkt – können darauf aufbauen. Beim Lernen für die ID-Prüfung fällt uns evtl. noch nicht auf, wie sehr wir davon profitieren, aber wenn wir später mal in einer Abschlussarbeit das PACT-Modell referenzieren können statt die Zusammenhänge immer wieder von Grund auf neu zu erklären, dann schon.

Leavitt-Raute und PACT-Modell

Nun zu Leavitt-Raute und PACT-Modell (vgl. S. 7 von ID_11-1.pdf). Was hat es damit auf sich? Die beiden Modelle sind sich so ähnlich, dass ich wohl zu beiden gleichzeitig etwas sagen kann.

Bei der Entwicklung von benutzergerechten Systemen kann vieles schiefgehen. Als Entwickler müssen wir viele Dinge auf einmal im Blick behalten. In den beiden genannten Modellen haben wir eine Reihe von Begriffen (Leavitt-Raute: Mensch, Aufgabe, Organisation, System; beim PACT-Modell kommt noch die Technologie hinzu) und Doppelpfeile, die jeden (PACT: beinahe jeden) Begriff mit jedem anderen verbinden. Was soll uns das sagen? Vielleicht betrachten wir erst mal die Begriffe nacheinander isoliert:

Mensch (people): Unsere Systeme werden von Menschen verwendet. Menschen haben unterschiedliche Fähigkeiten, körperliche und geistige Voraussetzungen, Erfahrungen, Neigungen und Geschmäcker. Beim Entwickeln von gebrauchstauglichen Systemen soll uns klar sein, wer unsere Zielgruppe ist.

Aufgabe (activity): In aller Regel will jemand, der eine Software benutzt, dadurch etwas erreichen. Die Zeiten, in denen Computer nur im Kontext von Arbeitsplatztätigkeiten betrachtet werden müssen, sind zwar vorbei, aber dennoch werden sie nicht ohne irgendein Ziel eingesetzt (und sei es Spaß oder Bewältigung von Langeweile). Die Gestaltung eines Systems hängt in nicht geringem Maße davon ab, welche Aufgaben man damit erfüllen können soll.

Organisation (context): In welchem organisationellen Kontext wird das System eingesetzt? Ist es eine Firma (eine konkrete?), ein Verein, eine lockere Community? Das System muss sich in bestehende Regelsysteme eingliedern lassen und sollte die Zusammenarbeit unterstützen.

System (system): Das System selbst, die Komponente, über die wir die größte Kontrolle haben.

Technologie (nur im PACT-Modell): Der technologische Rahmen, Ein- und Ausgabehardware, Ressourcen.

Das alles sind Dinge, die wir im Kopf haben müssen, wenn die Entwicklung gebrauchstauglicher Systeme gelingen soll. Die zentrale Aussage der Leavitt-Raute und des PACT-Modells ist nun dies: All diese Dinge stehen sehr eng miteinander in Beziehung. Man kann quasi nichts davon verändern, ohne Einfluss auf den Rest zu nehmen. Verändern wir den Nutzerkreis (die Menschen), dann verändern sich deren Aufgaben und Ziele. Verändern wir den Organisationskontext, treffen wir auf unterschiedliche Technologien. Ich glaube, die Urheber des PACT-Modells möchten uns primär dazu aufrufen, keine kurzsichtigen Veränderungen am System oder an anderen Bereichen zu machen, ohne über die Konsequenzen im großen Maßstab nachzudenken.

Interaction Space, Visualization Space, Display Space

Die Folien dazu sind MIA11-4.pdf, Seiten 3 bis 19, also beinahe die komplette Datei. Zu Anfang wird das Modell allgemein dargestellt, danach kommen Folien, die die einzelnen Teile konkretisieren.

Beim Spaces-Modell handelt es sich, oh Wunder, um ein Modell. Es greift also auch hier alles, was ich oben über Modelle geschrieben habe. Es stellt einen Versuch dar, etwas Fließendes und Kontinuierliches zu diskretisieren und zu beschreiben.

In dem Modell kommen vier Spaces vor: Interaction Space, Display Space, Visualization Space und Internal Model.

Der Interaction Space bezeichnet den Raum, in dem der Benutzer physisch auf das System einwirkt. Die mentalen Vorgänge des Benutzers zählen nicht dazu, ebensowenig wie die internen Vorgänge im System. Zum Interaction Space gehört normalerweise der Körper des Benutzers und sämtliche Steuerungs- und Sensorik-Hardware. Je nachdem, wie die aufgebaut ist, ist es mehr oder weniger leicht, dem Interaction Space eine Dimensionalität zuzuordnen. Wenn ich nur über eine Maus verfüge, dann ist er zweidimensional, ein VR-Handschuh wäre dreidimensional.

Der Display Space ist der Raum, in dem die Ausgabe des Systems stattfindet. Das kann ein zweidimensionaler Monitor sein, aber auch eine dreidimensionale Cave, ein dreidimensionales Richt-Schall-System oder andere abenteuerliche Dinge. Wichtig ist, dass zum Display Space nicht das gehört, was dargestellt wird (das kommt gleich), sondern nur die Hardware, auf der es dargestellt wird.

Der Visualization Space ist nun der Ort, der auf/durch unsere(n) Displays grafisch dargestellt wird. Der kann ebenfalls typischerweise zweidimensional (Desktop) oder dreidimensional (3D-Spiel, VR-Umgebung) sein, andere Dimensionalitäten sind ziemlich selten. Auffallend ist hier, dass man auf einem 2D-Display-Space einen 3D-Visualization-Space (mit Abstrichen in der Immersion) darstellen kann, sowie auch einen 2D-Visualization-Space auf einem 3D-Display-Space (was allerdings allein wegen der Kosten wahrscheinlich kaum jemand macht).

Eng mit dem Visualization Space verbunden ist das Internal Model, was beschreibt, wie das System intern den Visualization Space beschreibt und speichert. Zum Beispiel könnte das System abgesehen von den Raumdimensionen noch weitere Werte als Dimensionalität abspeichern (z.B. Luftdruck in jedem Punkt), die in der Visualisierung so zunächst nicht sichtbar sind. Der Unterschied zum Visualization Space ist, dass das Internal Model alles enthält, was „unter der Haube“ des Systems in der berechneten Welt stattfindet.

Artikulatorische und semantische Distanz

Diese Schlagworte finden sich in ID_11-2.pdf auf Seite 9 (und wie mir scheint auch nur an dieser einen Stelle) im Bezug zu dem Diagramm auf der gleichen Seite.

Die eine Achse des Diagramms ist mit „Direktheit“ beschriftet. Die semantischen und artikulatorischen Distanzen sind Aspekte, die die Direktheit negativ beeinflussen. Greifen wir uns ein paar Beispiele aus dem Diagramm.

Dort stehen Assemblersprachen unter sehr niedriger Direktheit eingeordnet. (Achtung: Gemeint ist hier die Direktheit zu den mentalen Prozessen des Benutzers, nicht zur Arbeitsweise der Maschine.) Assemblersprachen besitzen eine hohe artikulatorische Distanz, da sie vom Denken und Reden des Menschen relativ weit weg sind. Die eigenen Gedanken müssen vergleichsweise mühsam in das krude Vokabular der Assemblersprache übersetzt werden, bevor sie ihre Wirkung entfalten können. Dagegen hat ein Text in einer Fachsprache, die in das Diagramm unter sehr hoher Direktheit eingeordnet ist, idealerweise eine Eins-zu-eins-Entsprechung von den dahinterstehenden Gedanken und den formulierten Worten. Dazwischen steht wenig Übersetzungsaufwand oder „Umdenken“.

Die semantische Distanz meint dagegen eine Kluft zwischen den Möglichkeiten des Agierens. So hat etwa eine virtuelle 3D-Welt mit hohem Immersionsgrad vermutlich auch eine geringe semantische Distanz, weil zwischen meinem Ziel „mich vorwärts bewegen“ und der im System möglichen Aktion „die Kamera bzw. den Avatar vorwärts bewegen“ eine starke Kongruenz besteht. In einem Textadventure muss ich dagegen mein „vorwärts bewegen“ in ein textuelles Kommando übersetzen, dies eintippen und die Rückmeldung verarbeiten. Der Anwendungskontext „Navigation durch eine Welt“ leidet unter der semantischen Distanz zur Funktionalität „Manipulation von Textkommandos“. Ich hoffe dafür steigen mir jetzt keine Textadventure-Fans aufs Dach – ich möchte nicht gesagt haben, dass es keinen Spaß machen kann.

Zu alldem möchte ich anmerken, dass ich das auch nur aus den wenigen Stichworten extrapoliert habe, die auf der Folie stehen. Es kann durchaus sein, dass ich dabei Fehler gemacht habe. Verlasst euch bitte nicht darauf, dass ich die Weisheit mit Löffeln gegessen habe – vor allem falls eure Interpretation von meiner abweicht bin ich sehr interessiert daran.