6 Hinweisreizparadigma

Nun, da wir Grundkenntnisse über die Funktionsweise von OpenSesame haben, erstellen wir unser erstes richtiges Experiment. Wir werden eine leicht abgewandelte Form des Hinweisreizparadigmas (Posner, 1980) mit peripheren Hinweisreizen (auch exogene Hinweisreize genannt) und zentralen (oder endogene) Hinweisreizen erstellen.

6.1 Hintergrund und Design

Das Hinweireizparadigma geht auf Studien von Michael Posner zurück und beschäftigt sich mit der Frage, ob und welche irrelevanten Reize unsere visuelle Aufmerksamkeit anziehen, obwohl sie ignoriert werden sollten. Das Design des Experiments kann in Abbildung 1 gesehen werden. Posner bat seine Versuchspersonen, nach einem Zielreiz zu suchen und auf diesen zu reagieren. Dieser Zielreiz konnte an einer von zwei Positionen auftauchen.

Trulli
Abbildung 1: Ein Durchgang in einer klassischen Variante des Hinweisreizparadigma von Posner (1980) mit einem peripheren Hinweisreiz. Da der Hinweisreiz und der Zielreiz an unterschiedlichen Positionen auftauchen, spricht man hier von einem invaliden Durchgang. Aufgrund der Konvention in der Literatur wurden hier die englischen Begriffe verwendet.



Posner lies seine Versuchspersonen zwei Bedingungen durchlaufen, in denen sie mit verschiedenen, zeitlich kurz (100 ms) vor dem Zielreiz auftauchenden Hinweisreizen konfrontiert wurden. In der sog. peripheren Hinweisreizbedingung tauchte ein für die Aufgabe vollkommen irrelevanter Reiz, der sog. Hinweisreiz (auch engl. cue) für 50 ms an einer der beiden möglichen Zielreizpositionen auf. Die Bezeichnung Hinweisreiz ist dabei etwas irreführend: der Hinweisreiz tauchte nur auf Zufallsniveau (d.h. in nur 50% der Durchgänge) an der korrekten Zielreizposition auf. Versuchspersonen wurden auf diesen Umstand hingewiesen und dazu angehalten, den Hinweisreiz so gut wie möglich zu ignorieren. Wenn der Hinweisreiz an derselben Position wie der kurz darauf erscheinende Zielreiz auftaucht, spricht man von einem validen Durchgang. Erschien der Hinweisreiz hingegen an der Position, an der der Zielreiz nicht auftaucht, spricht man von einem invaliden Durchgang.

Die sog. zentrale Hinweisreizbedingung war bezüglich des Aufbaus ident zur peripheren Hinweisrezbedingung: 100 ms vor dem Zielreiz tauchte ein Cue für 50 ms auf, der die korrekte Zielreizposition lediglich auf Zufallsniveau vorhersagte. Die Cues in beiden Bedingungen unterschieden sich jedoch wesentlich voneinander: während der periphere Cue direkt an einer der beiden Zielreizpositionen auftreten konnte, wurde der zentrale Cue in der Bildschirmmitte präsentiert und war ein sog. symbolischer Hinweisreiz. Symbolisch beschreibt in diesem Kontext die Tatsache, dass der Cue ein Pfeil war, der entweder nach links oder nach rechts wieß und man diesem Cue erst eine Bedeutung zuweisen musste, während der periphere Cue eine mögliche Zielreizposition direkt anzeigte.

Wir werden in unserem Experiment hier lediglich auf non-prädiktive Cues, d.h. Cues, die bezüglich der darauffolgenden Zielreizposition uninformativ waren, eingehen. Posner hatte noch eine weitere Bedingung: eine prädiktive Cue-Bedingung. In dieser Bedingung zeigte der Cue in 80% der Durchgänge die korrekte Zielreizposition voraus.

Posner fand in seinem Experiment, dass periphere Cues die Aufmerksamkeit immer automatisch anziehen, egal ob die Versuchspersonen wussten, dass der Cue informativ oder uninformativ war. Im Gegensatz hierzu fand Posner, dass zentrale Hinweisreize die Aufmerksamkeit nur dann anziehen, wenn sie die korrekte Zielreizposition überzufällig oft korrekt vorhersagten. Waren die zentralen Cues gleich oft valide wie invalide, zogen sie die Aufmerksamkeit nicht an.

Wie aber operationalisierte Posner die Aufmerksamkeitsanziehung? Posner maß die Aufmerksamkeitsanziehung mittels dem sogenannten Validitätseffekt: schnellere Reaktionszeiten (oder RTs, für engl. response times) in Durchgängen mit einem validen Hinweisreiz, verglichen mit RTs aus Durchgängen mit einem invaliden Hinweisreiz. Der Validitätseffekt wird weitläufig als Evidenz dafür gesehen, das der eigentlich irrelevante Hinweisreiz die Aufmerksamkeit auf sich zog und der Zielreiz in einem invaliden neu gesucht werden musste, während die Aufmerksamkeit in einem validen Durchgang bereits an der korrekten Position verharrte. So trivial diese Erkenntnis zunächst wirken mag, verdeutlichen wir uns das extrem kurze Interval zwischen dem Auftreten des Hinweisreizes und dem Auftreten des Zielreizes, nämlich 150 ms: dieses Intervall ist zu kurz um eine Sakkade (Blickbewegung) hin zu dem Hinweisreiz auszuführen. Das Hinweisreizparadigma misst also verdeckte Aufmerksamkeitsverlagerungen, die unabhängig von der Blickrichtung auftreten.

6.2 Design in OpenSesame

Wie in Abbildung 1 ersichtlich, brauchen wir pro Durchgang, egal in welcher Cue-Bedingzung fünf Bildschirme: Den Fixationsbildschirm, den Cuebildschirm, einen weiteren Fixationsbildschirm für das Intervall zwischen Cue und Target, den Targetbildschirm, sowie einen weiteren Fixationsbildschirm während der Antwort.

Die Aufgabe der Versuchspersonen wird es sein, den Cue zu ignorieren und auf das Target zu antworten. Das Target kann entweder ein E oder ein H sein. Wenn das Target ein E ist, soll die Taste y gedrückt werden. Wenn das Target hingegen ein H ist, soll die Taste m gedrückt werden. Wir haben also die folgenden Merkmale, die im Experiment variieren:

Seite des Cues: links oder rechts

Seite des Targest: links oder rechts

Cue-Bedingung: peripher oder zentral

Buchstabe: E oder H

Die Variablen Seite des Cues, Seite des Targets und Buchstaben werden innerhalb eines Blocks variiert. Man spricht hier auch von einem sog. mixed Block. Die Variable Cue-Bedingung wird hingegen zwischen den Experimentalblöcken variiert: Versuchsperson erledigen einen Block mit zentralen Cues und einen Block mit peripheren Hinweisreizen. In der wissenschaftlichen Literatur würde man sagen, dass Variable Cue-Bedingung geblockt ist.

Beginnen wir nun mit dem generellen Aufbau des Experiments und starten mit der peripheren Cue-Bedingung.

6.2.1 Periphere Hinweisreize

  1. Wir öffnen ein neues Experiment in OpenSesame und wählen die Standardvorlage aus. Die Notiz getting_started können wir mittels Rechtsklick löschen. Das Sketchpad welcome verwenden wir gleich im nächsten Schritt.

  2. Bevor wir die Durchgangssequenz (engl. trial_sequence) im Experiment beginnen wollen, müssen wir unseren Versuchspersonen zunächst natürlich die Aufgabe erklären, die sie erwartet. Wählen wir dazu das welcome-Sketchpad aus und ändern den Namen in Instructions. Auf dem Sketchpad steht bereits der OpenSesame-typische Begrüßungstext. Schweben Sie mit der Maus über dem Text, bis er grau hinterlegt ist und klicken Sie den Text mittels Doppelklick an. Ein neues Fenster öffnet sich, in dem Sie den Text bearbeiten können.

  3. Schreiben Sie Folgendes in das Fenster:

Herzlich Willkommen bei diesem Experiment!

Sie werden pro Duchgang zwei Bildschirme in schneller Abfolge sehen: einen Bildschirm mit einem irrelevanten Reiz und den Zielreizbildschirm.

Wenn Sie im zweiten Bildschirm (d.h., Zielreizbildschirm) ein H sehen, antworten Sie mit der Taste m.

Wenn der Reiz im zweiten Bildschirm ein E ist, antworten Sie mit der Taste y.

Versuchen Sie, den irrelevanten Reiz im ersten Bildschirm so gut wie möglich zu ignorieren und blicken Sie stets auf den Punkt in der Mitte des Bildschirms.

Das Experiment beginnt mit einigen Probedurchgängen.

Beliebige Taste zum Starten drücken.



Wir wollen zwei Blöcke realisieren, beginnen wir mit der peripheren Hinweisreizbedingung:

  1. Ziehen Sie ein Loop-Item in die Übersicht nach den Instruktionen und benennen Sie das Loop-Item in Peripher um.

  2. Öffnen Sie das Peripher-Item und schreiben Sie in die oberste Spalte, die blau hinterlegt ist block. In die erste Zeile darunter schreiben Sie peripher. Das Ergebnis sollte aussehen, wie in Abbildung 2.

Trulli
Abbildung 2:Das geöffnete Peripher-Loop-Item nach unserer Bearbeitung.



Die nächsten Schritte mögen etwas obskur wirken, folgen Sie aber dennoch den hier beschriebenen Schritten. Die Logik wird nachher noch näher erklärt.

  1. Ziehen Sie ein Sequence-Item in den Überblick und lassen es auf dem Peripher-Loop-Item los. Es öffnet sich nun ein Dialog-Fenster, das Sie fragt, ob Sie das Sequence-Item in das Loop-Item einfügen wollen oder danach. Wählen Sie die Alternative In Peripher einfügen und benennen Sie die Sequenz in Peripher_Seq um.

  2. Ziehen Sie ein weiteres Loop-Item in den Überblick und lassen Sie es auf dem eben erstellten Peripher_Seq los. Wählen Sie die Option In Peripher_Seq einfügen. Benennen Sie das neue Loop-Item in Practice_Peripher um.

  3. Erstellen Sie, so wie Sie es eben im Peripher-Loop-Item gemacht haben, eine Variable indem Sie die erste Spalte in der ersten, blau hinterlegte Reihe auswählen. Tippen Sie nun practice in dieses Feld und gehen Sie in die Zeile direkt unter dieser neu erstellte Variable. Schreiben Sie nun yes in dieses Feld

  4. Ziehen Sie ein Sequence-Item in den Überblick und lassen es auf dem Practice_Peripher-Loop-Item los. Wählen Sie die Alternative In Practice_Peripher einfügen und benennen Sie die Sequenz in Practice_Peripher_Seq um.

  5. Ziehen Sie ein weiteres Loop-Item in den Überblick und lassen Sie es auf dem eben erstellten Peripher_Seq los. Wählen Sie die Option In Practice_Peripher_Seq einfügen. Bennenen Sie das neue Loop-Item in Practice_Trials_Peripher um.

  6. Nun sind wir bald am Ende der Verschachtelungen, versprochen. Ziehen Sie ein weiteres Sequence-Item in den Überblick und fügen Sie es in Practice_Trials_Peripher ein. Bennenen Sie diese Sequenz nun Trial_Seq_Peripher.

Nun sind wir endlich dabei angekommen, die eigentliche Sequenz ei- nes Durchgangs (siehe Abbildung 1) zu erstellen. Bislang sollte Ihr Experiment wie in Abbildung 3 aussehen.

Trulli
Abbildung 3: Unser bisheriger Fortschritt.



Verschachtelungen
Sie werden sich nun wohl fragen, was es mit diesen Verschachtelungen auf sich hat. Zugegeben, die Logik dahinter mag sich vielleicht nicht unmittelbar erschließen. Nützlich ist es jedoch vielleicht, den bisherigen Aufbau in Worte zu fassen: Hallo, i bims, ich möchte mit dem Block Peripher beginnen (vong Bedingung her). Der Peripher-Block soll wie folgt aussehen (d.h., soll folgende Sequenz sein; Peripher_Seq): Zunächst sollen die Versuchspersonen einen Block mit Trainingsdurchgängen absolvieren Practice_Peripher. Dieser Übungsblock sieht wie folgt aus (Practice_Seq_Peripher): Eine Trial Sequenz Trial Seq Peripher soll sich mehrmals wiederholen und dabei benötigte Variablen aus dem Loop-Item holen (mehr dazu gleich; Practice Trials Peripher). Der Vorteil an diesen Verschachtelungen ist, dass in jedem Durchgang, der durchgeführt und gespeichtert (geloggt) wird, die Variablen aus übergeordneten Loop-Items (bei uns: Peripher und Practice Peripher) für jeden Durchgang mitgespeichert wird, der Innerhalb dieser Strukturen ausgeführt wird. Das erspart uns einiges an Arbeit, wenn wir die Variablen der einzelnen Durchgänge spezifizieren.

  1. Nehmen Sie ein Sketchpad-Item und fügen es in die Trial_Seq_Peripher ein. Nennen Sie dieses Sketchpad Fixation_Peripher. Setzen Sie die Dauer des Fixationsbildschirms auf 995 ms.

  2. Nun machen wir uns daran, den Bildschirm so zu gestalten, wie er in der Abbildung 1 aussieht. Versuchen Sie sich selbst daran. In Abbildung 4 sehen Sie, welche Werkzeuge Sie dafür benötigen. Achten Sie besonders darauf, dass die Platzhalter symmetrisch sind und der Fixationspunkt in der Bildschirmmitte ist.

  3. Uns fehlen jetzt noch der Cuebildschirm, der Fixationsbildschirm für das Intervall zwischen Cue und Target (auch engl. interstimulus interval [ISI] oder cue-target onset asynchrony [CTOA]), der Targetbildschirm, sowie der weitere Fixationsbildschirm während der Antwort. Bevor wir nun aber alle Bildschirme so erstellen, wie das Fixation-Sketchpad, machen wir uns das Leben etwas einfacher. Klicken Sie mit der rechten Maustaste auf das Fixation-Sketchpad und wählen Sie die Option Kopieren (nicht verknüpft). Klicken Sie nochmals mit Rechtsklick auf das Fixation_Peripher-Sketchpad und wählen Sie die Option Einfügen. Nun sollte unter Fixation_Peripher ein weiteres Sketchpad mit dem Namen Fixation_Peripher_1 erscheinen. Benennen Sie Fixation_Peripher_1 in Cue_Peripher um und wiederholen Sie diesen Vorgang jeweils für die Bildschirme ISI_Peripher, Target_Peripher, Blank_Peripher und fügen Sie am Ende noch ein keyboard_response_item, sowie einen logger ein. Benennen Sie die letzten beiden Items in Response_Peripher und Logger_Peripher.

Trulli
Abbildung 4: Fixation_Peripher-Sketchpad nach unserer Bearbeitung. Die roten Pfeile sind natürlich nur als Hinweise gedacht und sollen nicht auf das Sketchpad gezeichnet werden. Links ist der bisherige Überblick zu sehen.



Verknüpfte und unverknüpfte Kopien
Sie können in OpenSesame verknüfte und unverknüpfte Kopien von Items erstellen. Bei unverknüpften Kopien erstellen Sie eine einfache Kopie. Wie Sie gerade erlebt haben, haben Sie das Fixation Display mehrfach kopiert und ihnen unterschiedliche Namen gegeben. Wenn wir in Kürze die übrigen Bildschirme so anpassen, wie wir sie haben wollen, können wir das für jeden einzelnen Bildschirm machen. Hätten wir von Fixation verknüpfte Kopien erstellt, so würde jede Änderung, die wir in einem Bildschirm vornehmen, auf alle anderen verknüpften Kopien übernommen. Bei den Änderungen, die wir vornehmen müssen, um unser Design zu realisieren, wäre das alles andere als zielführend. Zu einem späteren Zeitpunkt werden wir den Nutzen von verknüpften Kopien sehen.

  1. Öffnen wir den Cue_Peripher-Bildschirm und zeichnen einen Kreis (gefüllt) in einen der beiden Platzhalter. In diesem Fall zeichne ich den Kreis in den linken Platzhalter. Setzen wir die Dauer des Bildschirms auf 45 ms.

  2. Beim ISI_Peripher-Bildschirm müssen keine zusätzlichen Änderungen vornehmen. Wir müssen lediglich die Dauer auf 95 ms ändern.

  3. Im Target_Peripher-Bildschirm zücken wir nun das Textwerkzeug aus der Werkzeugleiste neben dem Bildschirm. Klicken Sie mit dem Stift in die Mitte eines Platzhalters und schreiben Sie einen der beiden Buchstaben (E oder H; bei mir: ein E im rechten Platzhalter). Wählen Sie eine Größe des Reizes so, dass Sie den Reiz gut zu erkennen glauben, wenn er nur sehr kurz präsentiert wird. Setzen Sie zudem die Dauer auf 45 ms.

  4. Setzen Sie die Dauer des Bildschirms Blank_Peripher auf 0. Ihr Experiment und die Bildschirme sollten nun so aussehen wie in Abbildung 5.

Trulli
Abbildung 5: Stand unseres jetzigen Experiments samt der einzelnen Bildschirme.



  1. Öffnen wir nun das Response_Peripher-Item (Abbildung 6) Wir möchten nicht, dass die Versuchspersonen andere Tasten außer die von uns spezifizierten Tasten verwenden. Geben wir daher bei Erlaubte Reaktionen y und m ein. Achtung: die beiden Buchstaben müssen durch ein Semikolon getrennt sein! Weiters wollen wir, dass Versuchspersonen nicht unbegrenzt Zeit für eine Antwort haben, sondern dass ab einer gewissen Zeit keine Antworten mehr registriert werden und das Experiment fortfährt. Geben wir daher bei Timeout 2000 (ms) ein.
Trulli
Abbildung 6: Das geöffnete Response_Peripher-Item.



Nun haben wir das grobe Design unseres Experiments erstellt. Wir haben definiert, wie welche Bildschirme wann und für wie lange gezeigt werden sollen. Nun ist ein angemessener Zeitpunkt, sich darüber klar zu werden, was es mit den eigenartigen Dauern auf sich hat.

Darbietungsdauern
Auch wenn es schön wäre, wir können unsere Reize nicht beliebig lange präsentieren. Den möglichen Darbietungsdauern werden Grenzen durch die Hardware (den Monitor) gesetzt. Bei einem klassischen Röhrenbildschirm wird ein Bildschirm Zeile für Zeile von oben bis unten und von links nach rechts gezeichnet: Trulli
Wie lange ein solcher Zyklus dauert hängt von der Bildwiederholungsfrequenz ab. Ein Bildschirm mit einer Bildschirmwiederholungsrate von 100 Hz dauert es 10 ms, bis ein neuer Bildschirm gezeichnet wird. Entsprechend sind die möglichen Darbietungsdauern 10 ms, 20 ms, 30 ms, … Hat ein Bildschirm eine Bildschirmwiederholungsrate von 60 Hz dauert es 16,6 ms, bis ein neuer Bildschirm gezeichnet wird. Entsprechend sind die möglichen Darbietungsdauern 16,7 ms, 33,3 ms, 50 ms, … Was hat das jetzt mit unseren schrägen Darbietungsdauern (995, 45, 95 und 45 ms) zu tun? Wir machen das, damit OpenSesame das Signal für den neuen Stimulus vor einem solchen neuen Zyklus sendet. Damit wird vermieden, dass der Monitor versucht, einen neuen Reiz während eines Zyklus zu zeichnen. Die Konsequenz wäre im schlimmsten Fall, dass lediglich ein halber Reiz gezeichnet wird.

Variablen in OpenSesame Wenn wir unser Hinweisreizparadigma nun ausführen, sehen wir lediglich einen Durchgang und sehen Hinweis- und Zielreiz lediglich an den Orten, die wir zuvor definiert haben. Hinweis- und Zielreiz sollen jedoch randomisiert links und rechts auftauchen. Zudem wird immer derselbe Zielreiz präsentiert. Anders gesagt, Hinweis- und Zielreizpositionen, sowie Zielreizidentität sollen variabel sein (hint, hint…).

Wir haben bereits eine Variable implementiert, nämlich die Variable practice mit der Ausprägung yes. Ähnliches tun wir nun mit den Variablen Hinweis- und Zielreizpositionen, sowie für Zielreizidentität.

  1. Öffnen wir also Practice_Trials_Peripher und tippen in die erste (blau hinterlegte) Zeile und die erste Spalte den Variablennamen cue_pos (für engl. cue position). In die zweite Spalte und wiederum die erste Zeile tippen wir target_pos. Zuletzt schreiben wir in die dritte Spalte letter. Wir haben soeben drei Variablen erstellt. Jede Zeile stellt einen Durchgang dar.

  2. Öffnen Sie nun die Skriptansicht Ihres Cue_Peripher-Sketchpads. Finden Sie nun die Zeile im Skript, in dem draw circle steht. Suchen Sie den zu dieser Zeile befindlichen x-Wert. In meinem Falle ist dies -256. Diese Zahl bezieht sich auf die Anzahl der Pixel, die der Reiz von der Bildschirmmitte entfernt ist. Das Minus bezieht sich dabei auf links, da die Bildschirmmitte die x- und y-Koordinaten 0 und 0 hat. Logischerweise folgt, dass die x-Koordinate des Cues, sollte er auf der rechten Seite auftauchen, das Vorzeichen wechseln muss.

  3. Tippen Sie die Koordinaten (bei mir: -256 und 256) in die ersten beiden Zeilen in der Spalte der Variable cue_pos.

  4. Gehen Sie für die Zielreizposition genauso vor, wie bei der Cue-Position und tippen Sie die Werte in die Spalte target_pos des Practice_Trial- Item.

  5. Im nächsten Schritt deklinieren Sie im Practice_Trial-Item alle möglichen Kombinationen durch.

  6. Erstellen wir eine zusätzliche Variable mit dem Namen correct_response. OpenSesame sucht von sich aus, ob es eine Variable dieses Namens gibt. Falls diese Variable existiert, vergleicht OpenSesame die gegebene Antwort mit dem Wert der Variable correct_response. Wenn die Werte übereinstimmen, speichert OpenSesame, dass der Durchgang korrekt beantwortet wurde (correct = 1). Wenn sich die Werte unterscheiden, gilt der Durchgang als inkorrekt beantwortet (correct = 1).

In Durchgängen, in denen die Variable letter ein E ist, soll die Variable correct_response y sein. In Durchgängen, in denen die Variable letter ein H ist, soll die Variable correct_response m sein. Die Tabelle sollte nun aussehen wie in Abbildung 7.

Trulli
Abbildung 7: Tabelle im Practice_Trial_Peripher-Item, auch Trialtable genannt.



  1. Eine gute und eine schlechte Nachricht: Wenn wir das Experiment nun durchführen, sollten keine Fehlermeldungen auftreten. Soweit die gute Nachricht. Die schlechte Nachricht: Die Reize tauchen immer noch stets an derselben Position auf und der Zielreiz ist immer derselbe Buchstabe. Die Lösung des Problems: wir müssen OpenSesame sagen, dass die x-Koordinaten der Cues und Targets die Werte der Variablen cue_pos und target_pos annehmen sollen. Weiters sollte der Zielreiz entweder ein E oder ein H sein, je nachdem, was in der Spalte letter steht.

  2. Öffnen Sie die Skript-Ansicht des Cue_Peripher-Sketchpads und schreiben Sie bei der x-Koordinate beginnend mit den Zeilen draw circle Folgendes: [cue_pos]. Durch die Verwendung der eckigen Klammern weiß OpenSesame, dass der Wert aus der entsprechenden Zeile der Variable cue_pos entnommen werden soll.

  3. Definieren Sie die x-Koordinate des Buchstaben im Target_Peripher-Sketchpad als [target_pos]. Ändern Sie zudem den Wert beim Parameter text zu [letter].

Lassen Sie sich nicht davon verunsichern, dass sich die Positionen des Cues und des Targets in die Bildschirmmitte verschoben haben. Das ist völlig normal. Wenn Sie das Experiment nun durchführen, sollten Sie acht Durchgänge des Hinweisreizparadigmas durchführen können.

Blöcke
Wir haben nun einen Übungsblock für unser Hinweisreizparadigma erstellt. Nun fehlt nur noch der eigentliche Experimentalblock, d.h., wir wollen noch einen zusätzlichen Block für die eigentliche Datenanalyse. Übungs- und Experimentalblöcke sind de facto ident, außer dass es mehr Experimentaldurchgänge als Übungsdurchgänge geben soll. Machen wir uns an die Arbeit!

  1. Bauen wir dieselbe Struktur von Loop- und Sequence-Items. Ziehen Sie dafür zunächst ein Loop-Item auf das Practice_Peripher-Loop-Item und wählen Nach Practice_Peripher einfügen und benennen Sie das neue Item in Main_Peripher um.

  2. Fügen Sie, wie im Practice_Peripher-Loop-Item die Variable practice ein und fügen Sie in der Zeile darunter no ein.

  3. Fügen Sie ein Sequence-Item in Main Peripher ein und benennen es in Main Seq Peripher um.

  4. Fügen Sie ein Loop-Item in Main_Seq_Peripher ein und benennen es in Main_Trials_Peripher um.

  5. Bevor wir uns wieder die Mühe machen, alle Durchgänge wie in Practice_Trials_Peripher händisch zu deklinieren, kopieren wir die Trialtable aus Practice_Trials_Peripher und fügen diese Tabelle in Main_Trials_Peripher ein. Das alles erfolgt mittels simplen Copy-and-Paste.

  6. Ändern Sie in Main_Trials_Peripher den Parameter Wiederhole jeden Durchgang 1,00x in Wiederhole jeden Durchgang 13,00x. Das bedeutet, dass jeder Durchgang 13 Mal wiederholt wird, die Versuchspersonen also 104 Versuchsdurchgänge absolvieren.

  7. Letzter Schritt: Wählen Sie die Trial_Seq_Peripher mittels Rechtsklick aus und wählen die die Option Kopieren (verknüpft) und fügen diese Kopie mittels Rechtsklick in Main_Trials_Peripher ein. Auf diese Weise können Sie Änderungen an den Bildschirmen vornehmen, die sowohl für Durchgänge im Übungs- als auch für Experimentaldurchgänge übernommen werden.

Vergewissern Sie sich, dass Sie verstehen, wie und warum wir das Experiment bislang so aufgebaut haben, wie wir es gemacht haben. Übersetzen Sie die Struktur des Experiments in eigene Worte. Was sagen wir OpenSesame mit jeder dieser Strukturen?
Wichtig: Wie bei allen Dingen, die mehr oder weniger mit Programmieren zu tun haben, gibt es zu jedem Ziel mehrere Wege. Sollten Sie eine experimentelle Architektur vor Augen haben, die zum selben Ergebnis kommen sollte, probieren Sie diese aus!

6.2.2 Zentrale Hinweisreize

Nun haben wir die erste Hälfte unseres Experiments gemeistert. Auch wenn Sie bis jetzt vermutlich mehr den Anweisungen hier gefolgt sind, das Verständnis über die korrekte Architektur verfestigt sich mit jedem neu erstellten Experiment mehr und mehr. Unser nächster Block ist komplett gleich aufgebaut wie der erste Block. Auch das Experiment per se ist beinahe ident. Lediglich der periphere Hinweisreiz verwandelt sich nun in einen Pfeil, der etwas über dem Fixationspunkt präsentiert wird (Abbildung 8).

Trulli
Abbildung 8: Hinweisreizparadigma mit zentralem Hinweisreiz.



In diesem Fall bietet es sich an, die komplette Struktur des ersten Blocks zu übernehmen. Beginnen Sie den neuen Block, in dem Sie ein Loop-Item auf das Peripher-Loop-Item ziehen und die Option Nach Peripher einfügen auswählen. Sie sehen, dass Ihr neues Loop-Item hierarchisch auf derselben Ebene ist, wie das Peripher-Item.

Den wichtigsten Schritt haben Sie somit getan. Nun erstellen Sie selbstständig eine Struktur, die identisch zu der Stuktur von Peripher ist. Der einzige Unterschied ist, dass Sie überall, wo zuvor *…_Peripher* eingefügt wurde, nun *…_Central* einsetzen. Das dient der Übersichtlichkeit des Experiments. Am Ende sollte Ihr Experiment aussehen wie in Abbildung 9.

Trulli
Abbildung 9: Struktur unseres neuen Blocks “Central”.



OpenSesame gibt eine Warnung aus, wenn es mehrere unverbundene Logger gibt. Mit einem Datenverlust ist nicht zu rechnen, wenn man mit der Standardeinstellung Protokolliere alle Variablen (empfohlen) arbeitet. Die elegante Lösung ist es jedoch, die beiden Logger_Central zu löschen und den Logger aus dem ersten Block verknüpft in den zweiten Block zu kopieren. Die Endung *_Peripheral* ist dann beim Logger natürlich sinnlos. Benennen Sie den Logger einfach Logger.

Nehmen Sie nun folgende Änderungen am Central -Block vor, bevor wir uns dem Cue-Bildschirm widmen:

  1. Erstellen Sie im Central-Loop-Item die Variable block (wie im Peripheral-Loop-Item) und geben Sie den Wert central in der Zeile darunter ein.

  2. Erstellen Sie im Practice_Central-Loop-Item die Variable practice und geben Sie in der Zeile darunter den Wert yes ein.

  3. Erstellen Sie im Main_Central-Loop-Item die Variable practice und geben Sie in der Zeile darunter den Wert no ein.

  4. Kopieren Sie die Trialtabelle entweder aus Practice_Trials_Peripheral oder Main_Trials_Peripheral, fügen Sie die Tabelle in Practice_Trials_Central und Main_Trials_Central ein und ändern Sie in der Spalte cue_pos alle negativen Werte zu left und alle positiven Werte zu right.

Jetzt haben wir alle Durchgänge, die wir im Block mit dem zentralen Hinweisreiz präsentieren wollen. Doch wie präsentieren wir die Pfeile? Wir werden die Pfeile als Bilder in das Experiment hineinladen. Sie können sich die Pfeile als PNG-Dateien unter chbuesel.shinyapps.io/experimenterstools (Tutorials → OpenSesame) herunterladen.

Laden Sie im nächsten Schritt die heruntergeladenen Bilder in OpenSesame. Öffnen Sie hierzu die Dateisammlung (maxkonmin) und klicken Sie auf das grüne Plus-Symbol. Wählen Sie im Dialogfenster die Bilder aus.

Öffnen wir nun das Cue_Central-Sketchpad und wählen das Bildwerkzeug (maxkonmin) aus. Tippen Sie mit dem Stift an eine Position leicht über dem Fixationspunkt und wählen Sie entweder white_arrow_left.png oder white_arrow_right.png. Sie finden neben dem Feld für Dauer ein Feld Skalierung. Ändern Sie die Größe des Pfeils, bis er in etwa so groß ist wie in Abbildung 10.

Trulli
Abbildung 10: Das Cue_Central-Sketchpad.



Sie werden nun vielleicht bereits etwas gemerkt haben: unsere cue_pos-Variable hat die Ausprägungen left und right und die Bilder haben die Endungen *…_left.png* und *…_right.png. Lassen Sie mich ehrlich zu Ihnen sein: das ist kein Zufall. Ebenso wie wir im Cue_Peripheral* den Wert der x-Koordinate durch den Wert der Variable [cue_pos] ersetzt haben, können wir einen Teil des Dateinamen des Bildes durch den Wert einer Variable ersetzen.

Öffnen wir die Skriptansicht des Cue_Central und ändern den file-Parameter von white_arrow_left.png auf file = white_arrow_[cue_pos].png. Das wars. So einfach. Schön!

Neuen Block testen
Wenn Sie nun ihren neuen Block durchführen wollen, werden Sie feststellen, dass Sie zuerst den kompletten ersten Block mit den peripheren Hinweisreizen erledigen müssten, um dann erst feststellen zu können, ob Ihr Experiment läuft. Gut, dass es hier Trick 17 gibt.

Klicken Sie auf das zweite Item im Überblick (maxkonmin experiment). Dort sehen Sie nun eine kurze und knappe Zusammenfassung ihres Experiments: ein Sketchpad-Item namens Instructions, ein Loop-Item namens Peripheral und ein Loop-Item namens Central (Abbildung 6.11). Daneben finden Sie den Beginn eines Konditionalsatzes: Durchführen, wenn.

Standardmäßig steht in der dazugehörigen Spalte always. Das bedeutet, dass OpenSesame die entsprechenden Items immer durchführt.

In dieser Spalte könnte man nun beliebige Bedingungen angeben. Zum Beispiel könnte man OpenSesame sagen, dass ein spezifisches Item nur durchgeführt werden soll, wenn die Versuchspersonennummer 12 [subject_nr] == 12 oder die Versuchspersonennummer ungerade ist [subject_parity] == “odd”.

Trulli
Abbildung 11: Die experiment-Sequenz.



Warum “==”?
Das Gleichheitszeichen hat in vielen Programmiersprachen eine besondere Bedeutung. Ein einfaches Gleichheitszeichen wird zur Zuweisung eines Wertes zu einer Variable verwendet. So bedeutet z.B.
a = 3,
dass die Variable a den Wert 3 annehmen soll.
Schreibt man jedoch
a == 3,
so fragt man, ob die Variable a den Wert 3 hat.
Kurz gesagt:
a = 3 → a ist gleich 3
a == 3Ist a gleich 3?

Um nun den Peripher-Block zu überspringen, machen Sie einen Doppelklick auf das always daneben. Ändern Sie always zu never. Wenn Sie das Experiment nun durchführen, starten Sie sofort mit dem Central-Block.

Wichtig: Vergessen Sie nicht, am Ende das Durchführen wenn-Argument wieder auf always zurückzusetzen.

In den nächsten Schritten werden wir lernen, wie wir den Versuchspersonen Feedback geben und Pausen ermöglichen können.

Ihr Experiment sollte gleich aussehen wie meines. Zur Kontrolle können Sie die momentane Version des Experiments auf der gleichen Seite wie die Hinweisreize des zweiten Blocks herunterladen.

6.3 Feedback und Pausen

Feedback
Feedback ist super. Nicht nur Lehrende freuen sich ganz besonders auf die letzte Lehrveranstaltungseinheit, auch Versuchspersonen bekommen ganz glasige Augen, wenn Sie nach den Durchgängen im Experiment Feedback zu Ihrer Leistung erhalten.

Aber jetzt im Ernst: Feedback hat nicht nur einen offensichtlichen Nutzen in den Übungsphasen eines Experiments, in der Versuchspersonen mit der Aufgabe vertraut werden sollen. Bestimmte Arten von Feedback während des Experiments können präventiv gegen unerwünschte Effekte verwendet werden. So kann ein Zu langsam!-Feedback nach einem Durchgang Versuchspersonen dazu animieren, schneller zu antworten, was in weiterer Folge sog. Speed-Accuracy-Trade-Offs verhindern kann. Zudem könnte das Darbieten von Falsch!-, nicht jedoch von Korrekt-Feedbacks eine Motivation sein, so korrekt wie möglich zu antworten - denn sind wir uns ehrlich: je schneller die Versuchsperson aus dem Experiment herauskommt, desto zufriedener ist sie.

Wir werden hier lediglich das Wrong-Feedback umsetzen. Sie können das Zu langsam!-Feedback zur Übung selbst erstellen. Ziehen wir ein Feedback-Item (maxkonmin) in die Trial-Sequenzen Trial_Seq_Peripher und Trial_Seq_Central und zwar nach den Logger-Items. Taufen wir das Feedback-Item wrong_peripher bzw. wrong_central. Schreiben Sie Falsche Antwort auf den Bildschirm und setzen die Dauer auf 495 ms.

Klicken Sie nun auf eines der folgenden Items: Trial_Seq_Peripher oder Trial_Seq_Central (Sie müssen den folgenden Schritt dann für die übriggebliebene Sequenz wiederholen). Klicken Sie mit einem Doppelklick auf das Durchführen, wenn-Statement neben dem neuen Feedback-Item und ändern always zu [correct] == 0. Wir sagen OpenSesame somit, dass das Feedback-Item wrong nur dann gezeigt werden soll, wenn die Variable correct in einem Durchgang den Wert 0 (= falsch) hat. Wenn die Variable jedoch den Wert 1 (= richtig) hat, dann soll die Folie nicht gezeigt werden.

Pausen
Wer arbeitet soll auch Pausen machen können. Erschöpfte Versuchspersonen neigen zu langsameren und weniger akkuraten Antworten. Ganz abgesehen davon: wir sind ja dankbar für die Teilnahme an unseren Experimenten, deshalb wollen wir die Testsituation so wenig belastend wie möglich gestalten.

In vielen Experimenten können Versuchspersonen die Pausen so lange (oder kurz) gestalten, wie sie wollen. Dasselbe werden wir bei unserem Experiment machen.

Auch wenn um die hundert Durchgänge am Stück verkraftbar sind, unsere Versuchspersonen werden nach der Hälfte jedes Blocks (d.h., nach 52 Main-Durchgängen) die Möglichkeit zu einer Pause haben. Ziehen wir also ein normales Sketchpad-Item an die letzte Position in einer Trial-Sequenz (wie bereits weiter oben muss dieser Schritt separat für die Trial_Seq_Peripher und Trial_Seq_Central Sequenzen gemacht werden). Das neue Sketchpad nennen wir nun Pause_Peripher bzw. Pause_Central. Klicken wir wieder auf die Sequenz eines Trials und klicken das Durchführen, wenn-Argument mittels Doppelklick. Wir machen uns nun wieder eine Variable zunutze, die OpenSesame automatisch loggt. OpenSesame nimmt nämlich von jeder Sequenz auf, wie oft diese wiederholt wurde. Das bedeutet, die Variable [count_Trial_Seq_Central] wächst in jedem Durchgang um den Wert 1. Geben wir also im Durchführen, wenn-Argument [count_Trial_Seq_Central]==52 ein. Das wars.

6.4 Balancieren

Wenn zu erwarten ist, dass die Erfahrung von Versuchspersonen aus dem ersten Block einen Einfluss auf deren Leistung im zweiten Block haben könnte (sog. Carry-Over-Effekte), sollte man diese Effekte über Versuchspersonen ausbalancieren. Das bedeutet, dass die Hälfte der Versuchspersonen das Experiment mit Bedingung A beginnt und im zweiten Block Bedingung B absolviert, während dies bei der zweiten Hälfte der Versuchspersonen genau umgekehrt geschieht. Stellen Sie sich vor, ein/e nette/r Reviewer/in bemängelt an unserem Experiment, dass es doch sein könnte, dass die Übung im ersten Block, die peripheren Hinweisreize zu ignorieren, das Vermögen der Versuchspersonen, die Hinweisreize im zweiten Block, also den zentralen Hinweisreiz, besser zu ignorieren, dann können wir kaum etwas sinnvolles darauf antworten. Es ist stets empfehlenswert, sich gegen solche (egal wie legitimen) Einwände durch ein ausbalanciertes und gutes experimentelles Design zu schützen.

Deshalb werden wir nun auch unser Experiment gehörig ausbalancieren. Öffnen wir dazu das experiment-Sequenz-Item, in dem wir Instruction, Peripher und Central aufgelistet sehen. Erstellen wir jeweils von Peripher und Central verknüpfte Kopien und ordnen Sie wie folgt an:

  1. Instructions

  2. Peripher

  3. Central

  4. Central

  5. Peripher

Die Anordnung mag etwas umständlich sein, da OpenSesame nicht kooperiert, wenn wir beispielsweise Central verknüpft kopieren und dann direkt auf Central ablegen und Nach Central einfügen wollen. Aber Sie schaffen das schon mit etwas hin und her (#towerofhanoi).

Wenn Sie diese Ordnung nun erreicht haben, ändern Sie das Durchführen, wenn-Argument von Peripher (2.) und Central (3.) auf [subject parity] == “even” und das Durchführen, wenn-Argument von Central (4.) und Peripher (5.) auf [subject parity] == “odd”. Ihr Resultat sollte aussehen wie in Abbildung 12.

Trulli
Abbildung 12: Die experiment-Sequenz nach der Balancierung.



Was haben wir jetzt gemacht? Wie bereits mehrfach erwähnt, führt OpenSesame einzelne Items chronologisch, d.h. von oben nach unten durch. Wenn ich jetzt beispielsweise Versuchsperson Nummer 2 (gerade) teste, dann geht OpenSesame die experiment-Sequenz wie folgt durch: Führe Peripher durch,wenn die Versuchspersonennummer gerade ist → trifft zu, führe Peripher durch → führe Central durch, wenn die Versuchspersonennummer gerade ist → trifft zu, führe Central durch → führe Central durch, wenn die Versuchspersonennummer ungerade ist → trifft nicht zu, führe Peripher nicht durch…

Bedingungen, die nicht zutreffen, werden nicht durchgeführt und Bedingungen, die zutreffen, werden in der Reihenfolge durchgeführt, wie sie im Experiment erstellt wurden.

Übungsaufgaben
Verschönern Sie das Experiment noch zusätzlich und ergänzen Sie folgendes im Experiment:

1. Fügen Sie einen Bildschirm im Experiment ein, der den Versuchspersonen sagt, dass die Übungsdurchgänge beendet sind und nun die eigentlichen Experimentaldurchgänge kommen.

2. Fügen Sie zwischen den beiden Blöcken einen Bildschirm ein, der den Versuchspersonen den nächsten Block erklärt. Achten Sie darauf, dass die Instruktionen für die unterschiedlichen Reihenfolgen (d.h., gerade und ungerade Versuchspersonennummern) korrekt angezeigt werden.

3. Fügen Sie ein Zu langsam!-Feedback ein, wenn Versuchspersonen langsamer als 1,5 Sekunden sind.

4. Fügen Sie ein Korrekt-Feedback ein, das gezeigt wird, wenn Versuchspersonen eine korrekte Antwort geben, aber nur im Training.

6.5 Inline-Skript: Randomisierte Fixationsdauer

In diesem Abschnitt werden wir uns ansehen, wie wir mithilfe eines Inline-Skripts die Dauer des Fixationsbildschirmes zufällig zwischen 800 und 1400 ms variieren können. Im Rahmen eines Cueing-Experiments ist das für gewöhnlich nicht unbedingt notwendig, nehmen wir jedoch einmal an, wir wollen messen, wie schnell Versuchspersonen auf einen Reiz reagieren: Ein stets gleich langes Intervall vor der Darbietung eines Reizes könnte zur Folge ha-ben, dass die Versuchspersonen das Auftreten des Reizes bereits antizipieren und nicht mehr die Antwort als Reaktion auf den Reiz ausführen, sondern weil sie sich an die fixierten Intervalle gewöhnt haben und schlicht in regelmäßigen Intervallen eine Antwort geben. Was haben wir in diesem Fall also gemessen? Die Geschwindigkeit der Reizdetektion? Die Fähigkeit der Versuchsperson, das Auftreten des Reizes vorherzusagen? Beide Möglichkeiten können leider nicht ausgeschlossen werden. Wie können wir nun also auschließen, dass Versuchspersonen das Auftreten eines Reizes vorhersagen können? Ganz einfach: wir variieren den Zeitpunkt, an dem der Reiz auftritt. In unserem soeben erstellten Hinweisreizparadigma variieren wir nun die Zeit, nach der der Hinweisreiz nach dem Beginn des Durchgangs auftritt.

Prinzipiell stehen uns zwei offensichtliche Wege zur Verfügung, diese Variation in OpenSesame zu implementieren:

  1. Fixationsdauer als Variable in die Trialtabelle einschließen: Prinzipiell ist es möglich, zusätzlich zu den Variablen, die wir in den Tri- altabellen definiert haben (cue pos, target pos, letter ), noch eine zusätz- liche Variable Namens dur (kurz für das englische duration, wobei die Benennung natürlich individuell bestimmt werden kann) zu erstellen und alle möglichen Dauern mit allen möglichen Kombinationen durch zu deklinieren. Die dabei entstandene Tabelle könnte dann beispiels- weise so aussehen: .tg {border-collapse:collapse;border-spacing:0;} .tg td{border-color:black;border-style:solid;border-width:1px;font-family:Arial, sans-serif;font-size:14px; overflow:hidden;padding:10px 5px;word-break:normal;} .tg th{border-color:black;border-style:solid;border-width:1px;font-family:Arial, sans-serif;font-size:14px; font-weight:normal;overflow:hidden;padding:10px 5px;word-break:normal;} .tg .tg-1wig{font-weight:bold;text-align:left;vertical-align:top} .tg .tg-0lax{text-align:left;vertical-align:top}
    dur cue_pos target_pos letter correct_response
    800 -256 256 E y
    850 -256 256 E y
    850 -256 256 E y


Prinzipiell ist dieses Vorgehen durchaus möglich, bringt jedoch mehrere Nachteile mit sich. Zum Einen ist sie recht aufwändig, da alle möglichen Kombinationen aller relevanten Faktoren korrekt aufgelistet werden müssen. Auch wenn es uns manchmal schwerfallen mag, es anzuerkennen, aber wir sind nicht perfekt. Das bedeutet, dass bei der Erstellung der Durchgänge (häufig) Fehler passieren können, die unsere Ergebnisse verfälschen könnten. Es uns beispielsweise passieren, dass wir einige kurze Fixationsdauern eher in validen Durchgängen realisieren, die langen Fixationsdauern eher in invaliden, aber nur, wenn der Hinweisreiz rechts erscheint etc. Solche Fehler können nicht nur aufgrund von Unaufmerksamkeit passieren, sondern schlicht daher, dass mit einer steigenden Anzahl an Faktoren die Anzahl an möglichen Faktorkombinationen exponentiell ansteigt. Hier den Überblick zu verlieren ist daher leicht möglich und auch verständlich.

Die steigende Anzahl der möglichen Kombinationen führt auch zu einem weiteren Problem: Die Anzahl der möglichen Kombinationen kann die Anzahl der von uns gewünschten Durchgänge schnell übersteigen. Nehmen wir beispielsweise an, wir wollen unser 2 × 2 Design in 100 Durchgängen testen. Wenn wir nun die Dauer des Fixationsbildschirmes als zusätzliche Variable in 16 ms Schritten15 variieren wollen (also 800 ms, 816 ms, 832 ms,… insgesamt 38 mögliche Ausprägungen) und dabei die jeweiligen Fixationsdauern für jede Faktorstufenkombination gleich wahrscheinlich haben wollen, dann ergeben sich insgesamt 304 mögliche Durchgänge (2*2*38) - mehr als wir durchführen wollen.

Wie entscheiden wir uns also dafür, welche 100 Durchgänge aus diesen 304 Durchgängen gezogen werden? Nun, wir könnten pro Versuchsperson 100 Durchgänge ziehen, in denen jeweils gleich viele valide wie invalide Durchgänge zu finden sind und die Fixationsdauern insgesamt über die Versuchspersonen mit der Validität der Hinweisreize unkorreliert sind. Klingt anstrengend? Ist es auch. Alternativ könnten wir alle möglichen Durchgänge in OpenSesame auflisten und dann in der Option Wiederhole jeden Durchgang 0,33 angeben (100/304 0,33). OpenSesame zieht in diesem Fall nur 100 Durchgänge aus den vorhandenen 304, wodurch wir wieder unsere gewünschte Anzahl an Durchgängen haben. Das Problem ist nur, dass wir nicht vorhersagen können, welche Durchgänge OpenSesame nun genau zieht. Es wäre möglich (wenn auch unwahrscheinlich), dass OpenSesame 80 invalide Durchgänge zieht und 20 valide, ein Szenario, das es absolut zu vermeiden gilt.

  1. Fixationsdauer nach dem Zufallsprinzip von Durchgang zu Durchgang determinieren: Alternativ können wir auch OpenSesame bzw. Python die Präsentationsdauer des Fixationsbildschirms auch selbst vor jedem Durchgang selbst determinieren lassen. Streng genommen könnte es zwar wieder sein, dass zufällig eher längere oder kürzere Darbietungsdauern in bestimmten Faktorkombinationen vorkommen (wir können den Zufall letztlich nicht kontrollieren), jedoch fallen mit dieser Vorgehensweise Probleme weg, mit denen wir mit der soeben diskutierten Möglichkeit der händischen Erstellung aller möglichen Durchgänge konfrontiert wären. Zum Einen werden die Durchgänge immer noch aus unserer Trialtabelle gezogen, in denen wir die Faktorstufen korrekt balanciert haben. Das bedeutet, dass es ausgeschlossen ist, dass es mehr valide als invalide Durchgänge gibt (nur zur Erinnerung, wir streben ein 50:50 Verhältnis an). Zum Anderen mag es eben sein, dass zufällig eine Versuchsperson tendenziell längere Fixationsdauern in invaliden oder validen Durchgängen hat. Da aber die Präsentationsdauern des Fixationsdisplays vor jedem Durchgang bei jeder Versuchsperson neu determiniert wird, sind sie unsystematisch.

Hätten wir wiederum beim Erstellen der Trialtabellen einen Fehler gemacht, dann wären alle Versuchspersonen mit demselben Problem konfrontiert und der Fehler wäre systematisch.

Lange Rede kurzer Sinn: lassen Sie uns endlich programmieren!

6.5.1 Das Inline-Skript Plugin

Trulli


Nun ja, Sie haben sich etwas zu früh gefreut. Wer wäre ich denn, würde ich nicht auch noch einen kleinen Hirtenbrief zum Inline-Script Plugin verfassen? Das Inline-Script Plugin stellt die Schnittstelle zwischen dem GUI von OpenSesame und der zugrundeliegenden Programmiersprache Python dar. Wir können das Plugin an eine für uns relevante Stelle ziehen und in einem kleinen Code-Editor unseren Python-Code schreiben, den OpenSesame dann umsetzen soll. Uns sind (beinahe) keine Grenzen gesetzt, was wir mit dem Inline-Script Plugin anstellen können. Wir können ganze Bildschirme mithilfe eines Inline-Scripts erstellen und präsentieren, Variablen definieren und berechnen, eigene Bedingungen definieren, in denen ein bestimmtes Ereignis stattfinden soll und so weiter und so fort.

Doch an welche Stelle sollte man sein Inline-Script Plugin im eigenen Experiment ziehen? Wie bereits an anderer Stelle erwähnt, geht OpenSesame chronologisch vor: die Elemente im Überblick (der Darstellung der Experimentalstruktur am linken Bildschirmrand) werden der Reihe nach ausgeführt. Das bedeutet, dass wir, wenn wir beispielsweise innerhalb eines Durchgangs mithilfe eines Inline-Scripts eingreifen wollen, das Plugin an eine Stelle innerhalb des Druchgangs ziehen müssen, dass chronologisch vor dem gewünschten Ereignis von OpenSesame ausgeführt wird. In unserem Fall bedeutet das also, dass wir das Plugin innerhalb des Durchgangs (also in Trial_Seq…) vor dem Fixationsbildschirm plazieren müssen.

Doch leider, bei aller Vorfreude, die bei Ihnen zweifellos schon herrscht: so weit sind wir noch nicht. Wie in den meisten Programmiersprachen sind auch bei Python nicht alle Funktionen, die wir benötigen, standardmäßig enthalten. Stattdessen stehen uns sogenannte Libraries (oder auch Packages) zur Verfügung, die eine Sammlung von thematisch zusammenhängenden Funktionen beinhalten. So kann es etwa Libraries geben, die ausschließlich statistischen Analysen gewidmet sind, während andere Libraries Funktionen beinhalten, die für die Astrophysik von besonderer Relevanz sind. Die Logik, warum nicht gleich alle existierenden Funktionen standardmäßig in Python verfügbar sind, liegt auf der Hand: kaum jemand benutzt regelmäßig alle verfügbaren Funktionen, da wir uns zunehmend in immer kleiner werdende Fachbereiche zersetzen und nur noch in immer kleiner werdenden Bereichentätig sind. Das bedeutet, dass es eine vollkommen überflüssige Ressourcenverschwendung wäre, hätten wir stets alle Funktionen jederzeit zur Verfügung.

Ein wichtiger erster Schritt ist es daher, die von uns benötigten Libraries in OpenSesame zu laden. Ziehen wir dazu ein Inline-Script Plugin ganz an den Anfang des Überblicks, benennen es in StartScript um und öffnen es mittels anklicken. Geben tippen sie dann in das dunkel hinterlegte Feld die folgenden Zeilen ein:

# load required packages
import random

Was haben wir hier gerade gemacht? Nun, ein allzu groß es Geheimnis sollte es nicht sein: wir haben soeben die Library bzw. das Package random importiert. Genauer gesagt hat die zweite Zeile das bewerkstelligt. Die erste Zeile beinhaltet einen Kommentar. Generell ist es sehr (sehr!) wichtig, jedweden Code ausführlich und verständlich zu kommentieren. Das erleichtert es nicht nur, Code mit Kolleginnen und Kollegen auszutauschen und den Code für sie verständlicher zu machen. Nein, sogar wenn man selbst nach einiger Zeit in einen Code schaut, den man selbst verfasst hat, wundert man sich oft, was man da eigentlich aufgeführt hat.

Kommentare erstellt man, in dem man vor dem Kommentar ein Doppelkreuz (“Hashtag”) setzt. Python (und somit auch OpenSesame) weiß dann, dass die nachfolgenden Zeichen keinen Code beinhalten und versucht daher auch gar nicht, diesen Code durchzuführen. Erstreckt sich ein Code über mehrere Zeilen, dann muss man am Beginn jeder Zeile ein Doppelkreuz setzen. Umgekehrt bedeutet das, dass man nach einem Kommentar in der nächsten Zeile wieder ganz gewöhnlichen Code schreiben kann.

import random ist der Befehl, mit dem man Python sagt Ich möchte im Folgenden das Paket random verwenden. Importiere also (bitte) alle Funk- tionen, die in diesem Package zu finden sind, damit ich sie verwenden kann. Gut, damit haben wir die erste Hürde gemeistert.

Nun gehts ans Eingemachte. Nehmen wir ein neues Inline-Script Plugin und ziehen es an den Beginn eines Durchgangs, also noch vor Fixation_Peripher oder Fixation_Central und benennen es in TrialScript um. Wichtig ist es, dass wir dieses TrialScript am Beginn eines jeden Trials haben wollen, unabhängig davon, ob der Hinweisreiz ein zentraler Pfeil oder ein peripherer Punkt ist. Da das Inline-Script überall gleich aussehen soll, können Sie es als verknüpfte Kopie an den Beginn der anderen Trial-Typen ziehen.

Wenn Sie das gemacht haben, ersetzen wir die bisherigen 995 im Feld Dauer der beiden Fixationsbildschirme (Fixation_Peripher und Fixation_Central) mit [dur]. Wir sagen OpenSesame also, dass die Dauer, für wie lange der Fixationsbildschirm gezeigt wird, durch die Variable dur (für engl. duration) bestimmt wird. Da wir diese Variable allerdings noch nicht definiert haben und sie auch nicht in unseren Trialtabellen auftaucht, müssen wir diese Variable erst initiieren. Gehen wir dafür wieder zu unserem StartScript und schreiben unterhalb des bereits existierenden Codes das Folgende: # initiate variables
var.dur = 0

Leider ist OpenSesame hier etwas inkonsistent: möchten wir OpenSesame außerhalb von Inline-Scripts sagen, dass es sich bei einem Wert um eine Variable handelt, schreiben wir den Variablennamen in eckige Klammern. Wollen wir allerdings innerhalb eines Inline-Scripts spezifizieren, dass es sich bei einem Wert um eine Variable handelt, die im Experiment verwendet werden soll, dann muss dem Variablennamen var. vorausgehen.

Spezifikation einer Variable in GUI:
[Variablenname]
Spezifikation einer Variable im Inline-Script:
var.Variablenname

Prepare-Run Strategie
Bevor wir uns weiter an die Arbeit machen, unsere Programmier-Skills zu beweisen, ist es wichtig, auf eine Eigenheit von OpenSesame einzugehen. OpenSesame funktioniert auf der Basis einer Prepare-Run-Strategie. Nehmen wir folgendes Beispiel: Wenn wir einen Bildschirm mit vier unterschiedlich gefärbten Quadraten zeigen wollen, dann muss der Code, der diese vier Quardate und Farben definiert, ausgeführt werden. Moderne Computer sind zwar sehr schnell, jedoch nimmt jede Operation eine gewisse Zeit in Anspruch. Nachdem der zugrundeliegende Code Zeile für Zeile ausgeführt wird, würden die Quadrate minimal zeitversetzt auf dem Bildschirm auftauchen bzw., sollte die Präsentationsdauer zu kurz eingestellt sein, könnte es sein, dass gar nicht alle Quadrate fertig gezeichnet würden. OpenSesame umgeht dieses Problem, indem es die einzelnen Bildschirme (und Variablen) vor dem Beginn eines Durchganges vorbereitet (prepare-Phase) und dann zur von uns spezifizierten Zeit diese vorgefertigten Bildschirme auf den Monitor projiziert (run-Phase). Das bedeutet, dass Code bereits ausgeführt wird, bevor er präsentiert wird.

In den Inline-Scripts wird uns angeboten, von dieser Strategie Gebrauch zu machen. Wie Sie vielleicht schon gesehen haben, gibt es zwei Reiter inner- halb des Inline-Script Plugins: Vorbereiten und Starten. Bei den bisherigen Zeilen Code war es noch folgenlos, in welchem Reiter wir den Code geschrieben haben, da es zu Beginn des Experiments noch egal war, ob der Code etwas früher oder später ausgeführt wird. Er wurde in beiden Fällen ausreichend früh ausgeführt, bevor die Inhalte im Experiment relevant wurden.

Gehen wir nun aber wieder zurück zu unserem TrialScript. Hier ist es nun wichtig, dass wir die nächste Zeile Code in die prepare/Vorbereiten-Phase schreiben:

# pick random value between 800 and 1400 for variable dur
var.dur = random.choice(range(800, 1401))

Eine so kurze Zeile kann schon so viel beinhalten, das man erklären sollte. Die erste Zeile stellt, wie bereits bekannt, einen Kommentar dar. Dieser ist an sich schon recht selbsterklärend. Da viele unter uns jedoch vielleicht noch nicht besonders mit Python vertraut sind, gehen wir die zweite Zeile etwas genauer durch.

  1. var.dur =: Hiermit geben wir an, dass wir der Variable dur, die in weiterer Folge von OpenSesame verwendet werden soll, jenen Wert zuweisen, der nach dem =-Zeichen folgt.

  2. random.choice(): Aus der im StartScript geladenen Library random verwenden wir die Funktion choice. Generell, wenn man in Python eine Funktion aus einer Library verwenden möchte, gibt man zunächst den Namen der Library, in dem sich eine Funktion befindet, an und trennt den Namen der Library vom Namen der Funktion mit einem Punkt. Mit der Funktion choice kann man einen zufälligen Wert aus einer Sequenz ziehen.

  3. range(800, 1401): Hier definieren wir die Sequenz, aus der ein zufälliger Wert gezogen werden soll, und zwar aus einer Sequenz, die bei 800 beginnt und bei 1400 endet.16 Prinzipiell wäre es auch möglich, der range()-Funktion einen dritten Parameter hinzuzufügen, nämlich, in welchen Schritten vom Start- bis zum Endpunkt gegangen werden soll. So würde beispielsweise der Befehl range(1, 10, 2) zu einer Sequenz von 1, 3, 5, 7, 9 führen. Sollten Sie sich nun denken, dass range(800, 1401) (was zu einer Sequenz von 800 bis 1400 in Einserschritten führt) ja die Bildschirmwiederholungsfrequenz außer Acht lässt, haben Sie absolut Recht. In unserem Fall ist jedoch das exakte Timing der Fixationsdauer weniger relevant, als die Tatsache, dass sie schlicht zufällig zwischen 800 und 1400 ms variiert.

Und mit diesen paar Zeilen und zwei Inline-Script Plugins haben wir es mittels Python zuwege gebracht, den Zeitpunkt des Auftretens der Hinweisreize dem Zufall zu überlassen und so für die Versuchspersonen unvorhersehbar zu machen. Klopfen Sie sich mal kräftig auf die Schulter.

Tipp: Sollten Sie sich unsicher sein, ob die Skripte bei Ihnen funktionieren, schreiben Sie mithilfe eines Text-Elements [dur] auf die Mitte Ihres Fixationsbildschirmes. Auf diese Art wird der zufällig gezogene Wert, der die Präsentationsdauer angibt, auf den Fixationsbildschirm geschrieben. So sollten die kleinen Variationen in der Dauer besser erkennbar sein.


  1. Da die minimale Präsentationsdauer bei einem Monitor mit 60 Hz 16,67 ms beträgt.↩︎

  2. Warum schreibt man nun aber range(800, 1401)? Nun, das ist eine der Eigenheiten von Python und es ist ratsam, sich das einfach zu merken, ohne zuviel ins Detail zu gehen. Es gibt in Python auch andere solche Eigenheiten. Möchte man beispielsweise wissen, welches Element sich an der ersten Position in einem Vektor oder einer Liste befinden (nennen wir diese einmal a), dann muss man sich diesen mit a[0] ausgeben lassen, da Python nicht bei 1, sondern bei 0 mit dem Zählen beginnt.↩︎