Pick a subset of blocks

Give each participant a random two of three self-contained tasks, each opening with its own instructions screen.

When to use it

Use this when the study bundles several self-contained tasks but each participant should only complete some of them, in random order, to keep sessions short while every task still collects data across the sample. Building one project per task combination fragments recruitment and the results; a block label per task plus one rules expression does the whole design in a single file. If every participant should run all tasks and only their order should vary, block-order shuffling with the randomBlock column is the right tool, and if the split should be a deliberate between-subjects assignment rather than a fresh draw per session, reach for the subjectGroup column instead.

Trial file

type	stimFormat	block	rules	title	content	stim1	keyboard	key	button1
instructions			block.sample(faces, words, sounds, 2)	Welcome	You will complete two short tasks, chosen at random. Each one starts with its own instructions.				NEXT
instructions		faces		Face task	Press F if the face looks happy and J if it looks sad.				NEXT
test	.png	faces				face_happy1	f j	f
test	.png	faces				face_sad1	f j	j
instructions		words		Word task	Press F if the letters form a real word and J if they do not.				NEXT
test	word	words				TABLE	f j	f
test	word	words				BLINT	f j	j
instructions		sounds		Sound task	Press F if the tone is high and J if it is low.				NEXT
test	.mp3	sounds				tone_high1	f j	f
test	.mp3	sounds				tone_low1	f j	j

How it works

The block column labels each contiguous run of rows as one named task, and crucially the label sits on the task’s instructions row too, so the screen travels with its block: kept when the block is kept, dropped when it is not, always at the head of its task. The welcome row stays unlabelled, and trials whose block value is not listed in a rule are never dropped or moved, so it runs first for everyone.

The rules cell holds the single expression block.sample(faces, words, sounds, 2). It runs once at experiment start: two of the three listed blocks are picked at random, the unpicked block’s rows are removed, and the two survivors are re-inserted in the random order they were sampled. Each surviving block’s internal row order is preserved, which is what keeps every instructions screen in front of its own trials. The rule applies to the whole experiment regardless of which row carries it; here it sits on the welcome row, which is safe because that row has no repeat value and no list expansion (a rule on a duplicated row executes once per copy and keeps removing blocks).

Two things deserve double-checking. Identifier matching is exact and case-sensitive, and identifiers may only contain letters, digits and underscores; with block.sample, a listed name that matches no row (a typo, a case mismatch) can break the experiment at startup or silently leave fewer blocks than the count. And all failure modes of a malformed expression are silent: a misspelt function name or a bad argument list simply does nothing, leaving all three tasks in the file. Preview the study and confirm only two tasks appear.

Each task then runs as ordinary trials: keyboard accepts F or J everywhere, and key scores the correct one per row into the correct results column. The picked blocks’ block values appear in the raw results download, telling you which tasks the participant got.

Variations

• Keep the file order instead of shuffling the survivors: block.select(faces, words, sounds, 2) in rules keeps 2 of the 3 blocks without reordering them.
• Change the count to 1 for a “one of three tasks” design; a count as large as the list keeps every listed block (and block.sample still shuffles their order).
• Make one task mandatory by leaving it out of the rule: unlisted blocks are untouched, so block.sample(words, sounds, 1) in rules runs the face task for everyone plus one of the other two.
• Shuffle trials inside the surviving blocks with plain run tags in random (rules run first, then randomisation applies to the kept trials). Use bare tags only: files combining block. rules with trialOrder specs are rejected when the trial file is saved.