When building questionnaires, many configuration settings can be set directly. Whether it's the question text itself or the range of options for a dropdown input, you can simply set the value you want in the tools:
In the case above, the screen will always have a time limit of five seconds. But this isn't always what we want - we might want different trials to have different time limits. Or we might want to have two experimental conditions with different time limits. Or we might have a task where the time limit changes dynamically depending on the participant's performance. We know we want a time limit, but we want to specify it somewhere else.
Instead of entering a value directly, we can instead dynamically link this field to another source of data - for example, a column in the spreadsheet, or an experimental manipulation. In Gorilla, we call this binding - we bind the field to a data source that allows it to be defined elsewhere. You can bind any configuration setting that has the little link icon ( ).
When building questionnaires, it's common for some questions to be conditional on the participant's response to other questions. For example, you may want to ask participants if they currently smoke, and if they do, whether they want to stop. If they don't currently smoke, we obviously don't want to ask them if they want to stop:
To do this, we can set the second of these two questions to be conditional, and set the condition to be that we've answered 'Yes' to the smoking question. These conditions will update in real time - any time the response changes, the logic will be evaluated and the visibility of the second question will update dynamically:
Manipulations are settings that you can control at the experimental level. Rather than have settings that are the same for every participant, this allows you to have settings which you can configure differently for different experimental conditions. For example, you may want all your participants to do the same questionnaire, but change a single page between two conditions:
By default, questionnaires advance to the next page, so to implement this we only need to add two branching rules: Page 2 should go to Page 4 if we are in the A condition, and Page 1 should go to Page 3 if we are not in the A condition:
When you add your questionnaire to an experiment, you can now configure manipulations separately for each instance of the questionnaire:
Each participant has their own unique Store - data that belongs to them and stays with them for the duration of the experiment. You can think of it as a little backpack or suitcase that each participant carries with them, and you can put values in there and then retrieve them again later. In the first generation of tools, this was referred to as Embedded Data - we've changed the name to Store because we think it's a better term, but it fulfils the same function.
The simplest use-case for the Store is when you want to save a participant's response and then use it later in the task. Note that this is separate from recording responses for your actual experimental data that you download once your participants have finished - participant responses are always recorded in your downloaded data; the Store is purely when you also want to be able to use a particular response later in the task.
For example, imagine an experiment where we want participants to do one task if they prefer cats, and a different task if they prefer dogs. We would have a questionnaire first that asks them whether they prefer cats or dogs, and then save that response to the store so that we can use it in a branch node later:
To do this, you simply select the response, enable 'Write To Store', and set the field you want to store it under. In this example, the choice of Dogs or Cats will be saved to a field called pet, which can then be used in the experiment tree or a future task:
