LUIDA Docs
Concepts

Questionnaires (qID binding)

How questions registered in the Web Console get rendered as in-Cluster UI when a state activates.

LUIDA splits questionnaire content (the questions, their wording, their answer options) from questionnaire placement (when in the experiment they appear). Content lives in the Web Console; placement happens in the Unity scene. The qID is what binds them.

Where questions live

You don't define questions in Unity. You define them in the Web Console:

  1. On your experiment's detail page, scroll to Questionnaires.
  2. Add a questionnaire — title, description, optional template (e.g., IPQ for Igroup Presence Questionnaire, SSQ for Simulator Sickness Questionnaire).
  3. Add questions to that questionnaire, one at a time. Each question has:
    • Title (the question text the participant reads)
    • Description (optional helper text or explanation of the scale)
    • Type, one of:
      • Radio Button — single-select from a list of options
      • Linear Scale — Likert-style, e.g., 1–7
      • Checkboxes — multi-select
      • Toggle — on/off, yes/no
      • Text Input — free-text
    • Answer options — comma-separated list (for Radio/Checkbox/Linear Scale)
    • Required — whether the question can be skipped

The Web Console assigns each questionnaire a position within your experiment — 1 for the first one you added, 2 for the second, etc. That position is the qID. Stable across edits, as long as you don't reorder.

Where questionnaires are placed in the experiment

In Unity, you don't bind a state to questionnaire content. You bind it to a qID:

  1. Open LUIDA › Configure experiment automation › State Machine.
  2. On the state where you want a questionnaire to appear, set its qID field to the position number from the Web Console.
  3. Make sure your scene has a Questionnaire prefab present (drop one from GameObject › LUIDA › Questionnaire).

When the state machine enters that state at runtime:

  1. The Questionnaire prefab activates.
  2. It calls the Web Console: callExternal({ type: "questions", eID, qID }).
  3. The Web Console returns the questions, paginated (in batches limited to ~1 KB to fit Cluster's payload constraints).
  4. The prefab spawns answer-option items (radio buttons, scale dots, etc.) for the participant to interact with.
  5. When the participant submits, the prefab calls callExternal({ type: "questionAnswers", eID, qID, pID, answers }).
  6. After submission, the prefab fires form_allPlayersCompleted once all participants in the session have submitted, which usually triggers the state machine to advance.

Why bind by position, not by ID

A trade-off: position-based binding is fragile (reordering questionnaires breaks the binding) but human-readable (researchers can read "qID 2 = post-experiment IPQ"). LUIDA chose position-based for the simplicity, with the implicit assumption that questionnaire ordering is stable once you start collecting data. If you reorder or insert in the middle after publication, you'll likely break sessions in flight.

A future version may switch to UUID-based binding with a friendly-name layer; for now, treat questionnaire ordering as part of your experiment's frozen contract once you publish.

Multi-participant questionnaires

If your experiment has pNum > 1, every participant in the session gets their own copy of the questionnaire UI when the state activates. Each participant's answers are recorded separately. The state machine waits for all participants to submit before advancing (via form_allPlayersCompleted).

Common pattern for paired studies: Participant 1 fills out a self-rating; Participant 2 rates Participant 1; advance to the next state when both have submitted.

Built-in templates

When you add a questionnaire on the Web Console, you can pick from templates:

  • IPQ — Igroup Presence Questionnaire (14 items, 7-point Likert) — measures sense of presence in VR.
  • SSQ — Simulator Sickness Questionnaire (16 items, 4-point Likert) — measures simulator sickness symptoms.
  • VEQ — Virtual Experience Questionnaire (planned; ask the LUIDA team for the latest status).

Picking a template auto-populates the questions in the standard wording. You can edit afterward.

Pre-experiment vs post-experiment

Almost every LUIDA study has at least one of each:

  • Pre-experiment questionnaire — demographics, prior VR experience, color vision, motion sickness susceptibility. Placed on a state right after participants enter and before the trial loop begins. qID = 1 typically.
  • Post-experiment questionnaire — presence (IPQ), workload (NASA-TLX), task-specific subjective measures, debrief. Placed on a state right before End. qID = 2 typically.

You're not required to have either. Some short pilots skip the pre-questionnaire entirely; some non-VR-presence studies skip the post-IPQ.

What gets stored

For every (session, participant, question) tuple, the Web Console stores:

  • experimentId, questionnaireId, participantsIdfc, participantsRole
  • answer[] (string array — single value for Radio/Toggle/Text/Linear Scale, multi-value for Checkboxes)
  • answerAt (timestamp)

There is currently no sessionId field on questionnaire answer records — meaning if you want to associate questionnaire answers back to a session for between-subjects analysis, you'd need to join on participant identifier and timing. This is acknowledged as a limitation; see the Web Console roadmap.

You download answers from the Web Console as CSV. Reshape into your stats software's preferred format from there.

Where to go next

On this page

Where questions liveWhere questionnaires are placed in the experimentWhy bind by position, not by IDMulti-participant questionnairesBuilt-in templatesPre-experiment vs post-experimentWhat gets storedWhere to go next