Help / Calendar / Running study sessions
Calendar
Running study sessions
Set up participant scheduling for an experiment end to end — session shape, screening, recruitment links, rooms and headsets, and what to do when the study ends.
This is the page to follow when you’re collecting data and need participants to book time with you. It assumes you’ve read Your availability and Booking pages ; here we put them together for a study.
The shape is always the same: describe the session once, decide who may book it, hand out a link, and let the calendar keep the schedule honest.
1. Work out the real session length
Write down the whole visit, not just the task. A “45-minute study” is usually closer to 90 minutes of room time once you count consent, the questionnaire, fitting the headset, and the debrief.
Split that into three numbers:
- Duration — the participant’s actual visit, from greeting to goodbye. This is what they see and plan around.
- Buffer before — your setup: booting the machine, loading the scene, resetting the guardian, laying out forms. Ten to fifteen minutes is typical.
- Buffer after — teardown: saving and labelling the data, wiping the headset, charging controllers, writing your observation notes. Do not skip this one. It is the single most common reason a data-collection day falls apart by the afternoon.
Set the duration to the visit and put the rest in the buffers. Participants then see an honest time commitment, and the calendar still refuses to stack sessions on top of each other.
2. Create the booking page
Make one event type for the study. A reasonable starting point for an in-person VR session:
| Setting | Value | Why |
|---|---|---|
| Title | The study, in participant language | “Virtual navigation study (90 min)” |
| Duration | 90 min | The visit itself |
| Buffer before / after | 15 / 20 min | Setup and sanitising |
| Minimum notice | 24 hours | You need a day to prepare and confirm |
| Booking horizon | 21–30 days | Don’t open a semester you haven’t planned |
| Location | In person, with the room number | Participants have never been in the building |
| Requires confirmation | On, if you screen | Nothing gets booked without you agreeing |
| Frequency limit | 3–4 per day | A realistic ceiling for hardware sessions |
| Additional guests | 0, or 1 if a companion may come | Accessibility, interpreters, minors |
Put everything the participant needs into the description: what they’ll do, how long it really takes, any exclusion criteria, whether they get compensated, where to park or which entrance to use, and who to contact if they’re running late.
Be specific about anything disqualifying — glasses, motion sickness, prior exposure to the task — before they travel across campus.
3. Decide who may book
This is the choice that separates a well-run study from a chaotic one. See Sharing your link for the mechanics.
- Screening first. Set the page to private and send an invite only to people who passed your screening questionnaire. The study calendar is invisible to everyone else, and each invite works once.
- Open recruitment. Set the page to public, turn on requires confirmation, and put the link on your flyer, your QR code, or the recruitment page. Anyone can request a slot; nothing is final until you approve it.
- Pilot inside the lab. Set it to internal and let lab members book without you publishing anything.
Screening first plus private invites is the safer default for anything with eligibility criteria. You do not want to explain to a participant who travelled to campus that they were never eligible.
4. Protect the room and the hardware
If the session needs a specific room or a specific headset that other people also use, attach it to the booking page as a resource — ask Francisco to add it if it isn’t there yet. The system then won’t offer a slot when that room or device is already taken, including by somebody else’s study.
Without this, two studies sharing one lab space will eventually book the same hour, and you’ll find out when both participants are standing in the doorway.
Track the physical gear itself in the equipment inventory — the scheduler knows the headset is busy, but not where it is or who last had it.
5. Staff it with more than one person
When several assistants can run the same protocol, make a team and set it to round-robin rather than giving each person their own booking page. Participants see the combined availability, which typically triples the offered slots, and each booking is assigned to whoever is least loaded.
Set a member’s weight to zero while they’re away, instead of removing them and rebuilding the team when they come back.
6. Run the sessions
Watch the Bookings list during the collection period. Approving, declining, rescheduling and cancelling are covered in Managing bookings .
Two habits worth having:
- Cancel no-shows rather than leaving them. A cancelled slot is a slot someone else can take, and the record is honest.
- Block your own days as you learn them. A new class, a lab meeting, a conference — add an override the day you find out, not the week it happens.
7. When the study ends
Turn the booking page off rather than deleting it. Disabling stops all new bookings and hides the page, but keeps the history of who came and when. Deleting it takes that record with it, and you’ll want the record when you write the methods section.
Close the availability window too, so a stale flyer in a hallway can’t produce a booking three months later.
Participant data: keep it minimal
The booking form collects a name, an email address, a timezone, and whatever the person writes in the notes. That is real personal data about a research participant, and it lives on lab servers.
- Don’t put participant details in titles or descriptions. The booking page is public; the name of the study is fine, a person’s name or condition is not.
- Don’t ask for anything sensitive in the notes field. It is a scheduling note, not a screening instrument. Health information, demographics, and anything your protocol treats as confidential belong in your actual study instrument.
- Keep the participant identifier mapping somewhere else. The scheduler should know that a person booked at 2 PM Thursday, not that they are participant 14 in condition B.
- Consent forms go through the e-signature service (opens in new tab) , not through the booking notes.
If your approved protocol says something specific about how scheduling data is stored or destroyed, follow that. Ask Francisco before wiring the scheduler into anything that touches identifiable data.
Source: content/systems/calendar/study-sessions.md · maintained in the lab docs repository.