ORSEE3

ORSEE is capable to manage multiple laboratories. On the session creation page you will have to specify the laboratory where the session will be conducted. At least one laboratory needs to be defined for the system to work properly.

On Options/Laboratories, use the 'Create new' button to add a laboratory, and the 'Edit' buttons to change existing laboratories. You can also drag a laboratory name up and down in the list, and save the order by clicking Save order. Select lists of laboratories will be populated in this order.

On the edit page of a laboratory you provide the laboratory name and the lab's address in all installed languages. Note, that the first line in the laboratory text field is considered the laboratory name, and the rest is used as the laboratory address. Both are used throughout the system.

Sub-Subjectpools (or subpools called in ORSEE slang) provide a way to organize your subject pool into groups. You can customize the participant profile form to a specific subpool (see Participant profile form and Participant profile template). Participants self-select to these subpools by choosing a self-description in the first step of their system registration process.

After choosing Options/Sub-subjectpools, the overview page shows the subpool names, descriptions and the number of subjects currently assigned to each pool. When creating or editing a subpool, you can edit the following settings:

• Name: State here the (informative) name for the subpool. This name will only be used internally to identify a subpool.

• Description: A short description of the subpool for internal use.

• Can request invitations for: Select the external experiment types (see section Experiment types) to which participants who self-selected into this subpool may subscribe to. Select at least one experiment type.

• Show subpool at registration page: Declare if the self-description (see below) of this subject pool should be shown at the registration page. if not, then subjects cannot self-select into this pool, but they may be assigned to this pool by an administrator.

• Registration page options: For each language installed in the system, provide a sentence which serves as a self-description for that subpool (see also the examples below).

There is a default sub-subject pool called not specified, that cannot be deleted. It serves as a catch-all in case no other subject pool is defined, or where the subpool id cannot be identified, and will never be shown at the registration page. So when you decide not to use sub-subjectpools at all, simply leave it as it is.

If you want to use this feature, create at least one own subpool and declare it as the default subject pool in Options/General settings. If there is only one own subject pool declared to be shown at the registration page, then the first step of the registration process (the self-selection) is skipped and the new participant is immediately assigned to this subpool. When more than one own subpools are defined and declared to be shown on the registration page, then the registration page will show a list of the self-descriptions and ask for selecting one of them.

When you delete a subpool using the 'Delete' button on the subpool edit page, you have to state to which other subpool its subjects (should there be any) will be moved.

As an example, you could have four subpools:

• Laboratory Students: invitations for - 'laboratory, internet and online surveys', show at registration page - 'yes', self description - 'I'm a student and I can participate at laboratory experiments in FancyTown'.
• Internet Students: invitations for - 'internet and online surveys', show at registration page - 'yes', self description - 'I'm a student, but I cannot come to FancyTown'.
• Laboratory Others: invitations for - 'laboratory, internet and online surveys', show at registration page - 'yes', self description - 'I'm not a student, but I can participate at laboratory experiments in FancyTown'.
• Internet Others: invitations for - 'internet and online surveys', show at registration page - 'yes', self description - 'I'm not a student and I cannot come to Jena to participate at laboratory experiments'.

Here, you could customize the participant profile form such that it asks for a field of study for the student pools and for a profession for the other pools.

Experiment types are used to organize experiments by type of the recruitment/session procedure. To provide the maximal amount of flexibility, ORSEE distinguishes between external and internal experiment types.

Internal types are nothing else than types of experiment organization implemented within ORSEE. Which types are available will depend on the ORSEE software version. The type classification is used internally to provide the right functionality in terms of the recruitment procedure. For example, for 'laboratory' experiments we need to create sessions and invite participants which then can register for that sessions. For a hypothetical type of online surveys (under development), we need to create the survey with pages and questions, and invited participants can directly participate at the survey over the Internet.

Currently, ORSEE only provides functionality for the internal type laboratory experiments. The types internet experiment and online-survey are only there for backward and forward compatibility. The only thing they currently allow is to create the experiment, to assign subjects and then to send them emails (for example to invite them to take part in some online experiment and to provide them with the URL to that website).

External types are types for which participants can agree to receive invitations for. You could think of different kinds of laboratory experiments you want to organise (e.g. video experiments, or experiments using physio-biological measurement, or brain scanners) and you might want to allow participants to decide for which type of these experiments they want to receive invitations for.

Thus, ORSEE allows you to create multiple external experiment types, each of which has to be mapped to at least one internal type. For example, the external type 'video experiments' will be internally considered as a 'laboratory experiment'.

On the external experiment type creation/edit page (Options/Experiment types), you are asked for the (internally used) name of the experiment type and a short description. Then you state to which internal experiment types this external type maps to. Just answer the question: To which of the internal types participants subscribed to this external type will be invited?

After that you fill in the public name of that type for all languages installed in the system. Use the Change button to save the data.

An external type can be assigned to more than one internal types, and more than one internal types can be assigned to one external type. Two examples:

• “Video experiments” are organized like laboratory experiments, so their internal type is “laboratory”. However, we require participants to agree explicitly to be invited for video experiments. Thus, in addition to our existing external type of (regular) Laboratory experiments, we create a new external type Video experiments, which also links to the internal type “laboratory”.
• We have the two internal types of “online-survey” and “internet” experiments. Internally, these two types will be organised differently (once new functionality has been implemented in future versions). But to the participants, they are the same kind of experiment, because both are conducted over the internet. Thus, we create one external type “Internet Experiments”, which links to both internal “online-survey” and “internet”. Participants who agree to receive invitations for “Internet Experiments” will be considered in both types of internal experiments.

Experiments can be tagged with keywords that then can be used to search for experiments or to exclude participants in experiment assignment queries based on the (tag) type of experiments they have participated in before. These keywords or tags are called experiment classes in ORSEE.

Experiment classes could include topics of experiments (e.g. 'dictator game', 'public good game', 'auctions'), types of rewards (e.g. 'course credit'), or give information about tools used (e.g. 'cognitive reflection test used'). On the experiment creation page you can assign one or more classes to an experiment.

In Options/Experiment classes you define the list of available classes/tags. The page displays the list of already defined experiment classes. Use the 'Create new' button to add a new class and the 'Edit' links to change to existing ones. You are asked to specify the description/name of the class for each installed language.

Participant profiles in ORSEE can be in different “states”, which define what the subject can do. In particular, a state is defined by its name, whether the subject has access to her profile, and whether the subject is eligible to participate in experiments.

There is one pre-defined state called Unconfirmed, to which a participant profile is assigned when a participant registers with the recruitment database and has not confirmed the registration yet by clicking on the respective link in the registration confirmation email. This state cannot be deleted, all you can do is to change the (internally used) name for this state.

At least one participant state has to be defined as Default for active participants. This is the state a participant will be assigned to when she confirms her registration yet by clicking on the respective link in the registration confirmation email. The default active state cannot be deleted, first another state has to be chosen as default active.

At least one participant state has to be defined as Default for inactive participants. This is the state a participant will be assigned to when she unsubscribes from the database. The default inactive state cannot be deleted, first another state has to be chosen as default inactive.

In addition to this minimum of three states, you can freely define other states. The default states in ORSEE >= 3.0 (corresponding to the implicit states in ORSEE <3.0) are Unconfirmed, Active (access to profile, eligible for experiments, default active), Unsubscribed (no access to profile or experiments, default inactive), and Excluded (no access to profile or experiments). The latter was defined to allow to single out profiles where the unsubscription was involuntarily, and in the default configuration this is the state a subject is assigned to when being automatically excluded by the reputation system (see section Reputation system).

Other states can be used to single out other kinds of participant profiles. As another example, you could create a state called Grey-listed, with access to the profile but no eligibility for experiments. This state could be used for subjects who are not officially excluded but who were so unreliable that you do not want to invite them to any further experiments.

When creating new participant state, you determine the internally used name of the state (in all installed languages), whether the participant has access to her profile and whether she is eligible to enroll for experiments, and whether this state is the default active or the default inactive state.

In addition, you are asked to state an error message (in all installed languages). This error messages only applies when the state settings are such that access to proifle is denied. When a participant in this state tries to access her profile, then access is denied and this message is shown.

A participation state describes the relation between a participant and an experiment (session) for which the participant is enrolled.

The is a default participation state Not set that cannot be deleted. It will be automatically assigned when a participant is made eligible for an experiment. For laboratory experiments, the state is also reset to No set whenever a participant cancels a session enrollment or enrolls / is newly enrolled for a session. Thus, for laboratory experiments, a participation state can be different from Not set only when the participant is enrolled for a session.

In addition to this default participation status Not set, you can freely define further participation states. These differ in their internal name and the name of the state that is displayed to participants, as well as in two properties:

• counts as participated: If this is selected, then it is assumed that the subject of this participation state has participated in the experiment. This will have consequences for eligibility criteria (e.g. exclusion based on prior participations), experience counts etc.
• counts as noshow: If this property is enabled, then assigning this state to a subject enrolled for an experiment session will increase the no-show count of the subject. Also, the subject will be included for no-show warning emails and potentially for automated exclusion based on the no-show count (see Reputation system).

The default participation states (corresponding to the implicit states in ORSEE <3.0) are Not set, Participated (subject showed up and participated in the experiment), Turned away (subject showed up but since there were too many participants she was dismissed with the show-up fee), and No-show (subject did not show up on time).

Custom participation states that detail the relation between subject and session further can be added. Examples are late-show (subjects who showed up too late for the session, but who shouldn't be counted as no-show), self-cancelled (when the feature is enabled in Options/General settings, a subject can cancel her enrollment by herself), researcher-cancelled (a researcher had to cancel the session for some reason), etc.

Note, however, that due to the software design that prevents dual participation at an experiment at the database level, whenever the participation state of a subject is different from Not set, she cannot enrol for any other session of the experiment.¹⁾