Support Home Response Processing

Response Processing

  • Introduction
  • Screen Hierarchy
  • Triggering Responses
  • Response Processing
  • Passive Responses
  • Response Tagging

Introduction


This guide will tell you more about how participants' responses are processed in Task Builder 2 and Game Builder, and help you better understand the order in which events happen on each screen.

In both Task Builder 2 and Game Builder, each individual screen follows the same basic sequence of events:

Schematic of event order: Screen start -> wait for response -> process response -> advance to next screen

Once the screen starts, we wait for responses from the participant. When one is received it, we process it - this might be marking it as correct or incorrect, or combining it with other responses - and then decide whether we should advance to the next screen or wait for more responses.

When you preview your task using the Play button in the Screen Editor, you can see a log of these events happening in the Debug tab:

When pressing the play button, a log of events is shown in the Debug tab.


Screen Hierarchy


Each screen is made up of a hierarchy of objects, each with components that control their behaviour. There is always a single screen object that is considered the 'parent' of the screen. This screen object always has a special component called the Screen Manager, which controls the sequence of events on the screen. All the objects that you can actually see on the screen - stimuli images, response buttons, instructions text and so on - are then child objects of the screen object:

Schematic of screen object containing Screen Manager component with 2 child objects containing Image and Text

The objects that you see on the screen are the ones you configure on the OBJECTS tab, and the screen is what you configure on the SCREEN tab:

Schematic with arrow from screen object to SCREEN tab of Object Editor, and arrow from child objects to OBJECTS tab

Triggering Responses


When a response is triggered, it is sent to the screen object. Most of the time, responses are triggered by objects on the screen that contain response components (Click Response, Keyboard Response etc). There are some special cases where the screen object itself might trigger a response (usually if the screen has a Time Limit component) - in this case, it simply sends the response to itself. Either way, the response is sent up the hierarchy to the screen object:

Schematic of a Click Response being sent up the hierarchy to the screen object

When a response is first triggered by an object on the screen, it contains three parameters:

  • The response itself - this is where you set the response that is recorded when a particular button or key is pressed. In a two-way forced-choice task you might simply label them A and B. If you are using image response buttons, you might want to name them after the images themselves. When scoring responses, this is the value that will be compared to the correct answer to establish whether it was accurate.

  • the reaction time - this is the time, in ms, between the start of the screen and when the response was received

  • the type - this will be one of the following:

response

Most responses use the response type - these are used for anything that is likely to be a scientifically interesting response. Most response components (e.g. Click Response) generate responses of this type, and most components that process responses (e.g. Scorer) only score responses of this type. Most of the time, it is likely that you can ignore any data in your output that doesn't use this type.

continue

The continue type is used for responses that simply trigger the screen to advance. This type is used by components such as Space To Continue and Click To Continue, which in turn are often used for advancing instructions screens where the actual response data is not scientifically interesting.

timed_out

the timed_out type is not a response that is actually entered by the participant - it is used by screens with a Time Limit when the time limit expires. These are often used on screens where a stimulus or fixation is shown for a set amount of time, and so shouldn't be confused with actual participant responses. The exception is screens where non-response within a time limit is scientifically interesting - see the Pro Tip box below for how to set up these screens so that a timeout generates a response rather than timed_out.

Pro Tip

Note that for Go/No-Go-style paradigms, where a non-response is also considered a legitimate response, you can set a no-go response in your time limit component on the Screen tab - this will cause the time limit to generate a response with the response type rather than the timed_out type, allowing you to treat it as a regular response.

The setup below will end the screen after 5 seconds and generate a timed_out response:

Screenshot of a Time Limit component. Time Limit is set to 5000 and Non Response is set to empty

The setup below will end the screen after 5 seconds and generate a response with the type response and the value NoGo:

Screenshot of a Time Limit component. Time Limit is set to 5000 and Non Response is set to NoGo

Response Processing


When a response is received by the screen object, it is then processed. Every component that you add to your screen object has the opportunity to either augment the response with more information, or respond to it in some way. For example, a Scorer component might compare the response to the correct answer to establish whether the response was correct, and a Save Response component might save the value of the response to the Store:

Schematic of a Scorer component scoring a response correct, and a Save Response component saving its value to the Store

Once all the processing is complete, the response is then saved as a metric - it will appear in your downloaded experimental data.

Finally, the screen object decides whether or not to advance to the next screen. The default behaviour is to always advance on the first response, but there are components such as Advance - Accuracy (which allows you to only advance on a correct or incorrect response) or Advance - Response (which allows you to only advance on a particular response) that you can use to change this.


Passive Responses


We often refer to responses that are triggered through clicks or keyboard presses as active responses - we wait for the participant to respond and capture both the response itself and the reaction time. However, sometimes we also want to capture responses using input methods that aren't a single click - sliders, text entry boxes, Likert scales and so on. We call these passive responses, because something else (e.g. a continue button or a screen timelimit) has to trigger the response to actually be submitted and processed.

Passive responses are only collected once the screen is ready to advance. The most common way to set this up is to add your passive response components to objects on the screen, and then add a Continue Button to trigger the screen to advance. In this way, the screen behaves similarly to a regular form or questionnaire. Alternatively, you could use a Time Limit component on the screen itself to give participants a limited amount of time to enter their responses. Either way, once the screen advance has been triggered, the screen finds all the passive responses and triggers them to submit their responses. These responses then go through the same process described above - they are all sent to the screen object, processed, and stored as metrics.

Response Tagging


When configuring an object that can trigger responses (such as an object containing a Click Response or Keyboard Response component), you also have the option of setting a tag. The main use case for Response Tags is for screens where you have more than one response. For example, consider a task which asks the participant to choose between two options, and also use a slider on a scale of 0-100 to indicate their confidence in their choice:

Schematic of a screen with a stimulus, two response buttons A and B, and a slider labelled 'Confidence'

If we want to save both the choice and the confidence rating to the Store, we need some way of telling Gorilla which one is which. We can't use the value of the response itself - the slider could be any of 101 different values - and we can't base it on the object whose component triggered the response, because the choice could be set by either button.

This is where Response Tags come in! We would tag the response buttons with one value (e.g. button) and the slider with a different value (e.g. slider). In our Save Response component, we can then configure it to save the button response to one field, called 'choice', and the slider response to another field, called 'confidence':


You can also optionally define different correct answers associated with different response tags. Add a Scorer (Multi) component to the Screen tab of the screen where you collect your responses. In the Correct Answer field, define the correct answer for one of your responses, and under 'And includes Tag', select the tag of this response. You can then add further Correct Answers for each of your other responses, in each case selecting the appropriate tag in the 'And includes Tag' dropdown. The Correct column in your data will then indicate whether each individual response on the screen was correct or incorrect. You can see an example of this in our Cloze Task sample.