LUIDA Docs
ComponentsWeb console

Building questionnaires

Add questions in the Web Console, pick from five types, use IPQ/SSQ/demographics templates, and bind to Unity states via qID.

These pages are not yet fully reviewed. The LUIDA team is continuing to review and improve them. If you find anything wrong on these pages, or have questions that aren't resolved by reading them, please ask or report to the LUIDA team.

Questionnaires are the survey side of LUIDA — pre-experiment demographics, mid-experiment manipulation checks, post-experiment scales like IPQ or SSQ. Content lives in the Web Console; placement happens in Unity. This page is the UI walk-through for building the content. For the binding model (how a qID ties Web Console questions to a Unity state), see Concepts → Questionnaires.

Screenshot pending — the Questionnaires section of an experiment detail page, with two questionnaires listed (Demographics + IPQ), plus the "Edit" view of the IPQ questionnaire showing a Linear Scale question expanded.

Where the editor lives

On any experiment detail page, scroll to the Questionnaires section. You'll see:

  • A list of questionnaires registered for this experiment, each with a title, description, item count, and an edit button.
  • A + Add Questionnaire button at the top.

Click + Add Questionnaire to open the questionnaire editor for a new entry; click Edit on an existing one to modify it.

Adding a questionnaire

The editor has two top-level fields plus a question list:

FieldPurpose
TitleShort label visible only to you — e.g., "Pre-experiment demographics" or "Post-IPQ".
DescriptionOptional helper text shown above the first question when the questionnaire renders in Unity. Use for instructions like "Please answer the following questions about your VR experience."
Template (optional)Pick from a dropdown to pre-populate the question list. See Built-in templates below.

After filling in the basic fields, + Add Question below the list inserts a new question. You can drag questions to reorder them with the handle on the left of each row.

The five question types

Each question has a Type field that controls what UI Unity renders for it and how answers are persisted.

TypeUI in UnityStored answer
Radio ButtonSingle-select buttons (one radio per option)One value from the option list.
Linear ScaleLikert-style row of dots (e.g., 1–7)Integer from the scale range.
CheckboxesMulti-select boxesAn array of selected option values.
ToggleOn/off switchBoolean (true / false).
Text InputFree-text fieldThe participant's typed string.

Per question, the fields are:

FieldRequired?Notes
TitleYesThe question text the participant reads.
DescriptionNoOptional helper text shown beneath the title.
TypeYesOne of the five above.
Answer optionsYes (for Radio/Checkbox/Linear Scale)Comma-separated list for Radio and Checkboxes. For Linear Scale, the option count determines the scale length (e.g., 1, 2, 3, 4, 5, 6, 7 for a 7-point Likert).
RequiredNoIf checked, the participant must answer before the questionnaire can be submitted.

The answer-option list for Radio / Checkboxes can be arbitrary strings — not just integers. For example, a Radio question for "Have you used VR before?" could have options Never, A few times, Many times, Daily. The stored answer is the option string the participant selected.

Reordering and qID

The questionnaire's qID is its 1-based position in the experiment's questionnaire list, assigned automatically:

  • The first questionnaire you add gets qID = 1.
  • The second gets qID = 2.
  • And so on.

If you reorder the list (drag a questionnaire above another), the qIDs reassign accordingly. This is the most common foot-gun: a Unity scene with qID = 2 configured on a state will start binding to a different questionnaire if you reorder the list.

Reordering after publication breaks any Unity scenes already binding to the old qIDs. Treat the ordering as part of your experiment's frozen contract once you start collecting data. If you absolutely have to reorder, either remap the Unity-side qID fields to match, or — better — add new questionnaires at the end instead of inserting in the middle.

Built-in templates

When you create a new questionnaire, the Template dropdown gives you pre-filled options:

  • IPQ (Igroup Presence Questionnaire) — 14 items on a 7-point Likert scale, measuring sense of presence in VR. Three subscales: spatial presence, involvement, experienced realism.
  • SSQ (Simulator Sickness Questionnaire) — 16 items on a 4-point Likert scale, measuring simulator sickness symptoms (nausea, oculomotor, disorientation subscales).
  • Demographics — age, gender, prior VR experience, etc. Free to modify; mostly there as a starting point.
  • VEQ (Virtual Experience Questionnaire) — planned; status varies by template version. Ask the LUIDA team for the latest.

Picking a template inserts all of its questions into the editor pre-configured. You can edit each question after insertion — change wording, add description text, mark a question optional. The template is a starting point, not a frozen artifact.

Multi-participant questionnaires

If your experiment has pNum > 1 (paired or group studies), the same questionnaire UI is rendered for each participant in parallel when the bound state activates. Each participant fills out their own copy; each participant's answers are persisted with their own participantsRole field.

The state machine waits for all participants in the session to submit before advancing (the form_allPlayersCompleted signal fires once everyone is done). This is automatic — you don't need to coordinate it from the Unity side.

For a paired-trust study or any design where one participant rates the other, this means: same questionnaire content, separate submissions, joinable on (sID, participantsRole) at analysis time.

Saving and previewing

The editor saves when you click Save at the bottom. There's no in-browser preview of how the questions will render in Cluster — to see the live UI, you'd need to run the bound state in CSEmulator or a test Cluster space. The rendering is deterministic per question type, so a CSEmulator pilot is usually enough.

Where to go next