Randomisation

Experiments Surveys & forms

Testable provides two classic columns for controlling how trials are randomly ordered at runtime: random for shuffling individual trials and randomBlock for shuffling whole blocks. For sampling, ordered selection, constrained randomisation, and reusable orders, use the newer trialOrder column described on the Trial Sequencing page. A third level lives inside a single trial: the order of its stimuli, covered further down under stimulus-level randomisation.

Trial-level randomisation: random

Assign the same number to a group of trials to randomise their order among each other:

random = 1
random = 1
random = 1

At runtime Testable shuffles each run of consecutive rows that share the same random value. Every group shuffles within itself: rows tagged 1 reorder among themselves, rows tagged 2 reorder among themselves, and the groups do not mix. Only a row with an empty random cell stays in its original position, and it also acts as a boundary: same-valued rows on either side of it shuffle as two separate groups.

Tip

0 does not switch randomisation off. It is a group value like any other, so rows tagged 0 shuffle among themselves. To keep a row in place, leave its random cell empty.

Block-level randomisation: randomBlock

The randomBlock column randomises whole blocks of trials. A block is a set of consecutive rows with the same randomBlock value. At runtime Testable shuffles the blocks, keeping the rows within each block in their original order.

Trial	randomBlock
Instruction A	1
Trial A-1	1
Trial A-2	1
Instruction B	2
Trial B-1	2
Trial B-2	2

The two blocks (rows with 1 and rows with 2) will be randomly ordered, so half the participants will see Block A first and half Block B first.

Multi-level block randomisation

Supply space-separated numbers to create nested randomisation:

randomBlock = 1 1
randomBlock = 1 1
randomBlock = 1 2
randomBlock = 1 2
randomBlock = 2 1
randomBlock = 2 2

The first number is the outer block level; the second is the inner level. Outer blocks are shuffled first, then inner blocks within each outer block.

Caution

Keep block identifiers simple: two levels is the maximum (a third space-separated number is not parsed correctly), and prefer numeric identifiers: letter identifiers still split blocks, but they break the fixed-separator behaviour of 0/empty cells next to them and can be silently corrupted (any value containing the letters na corrupts parsing). 1 1, 2 3 are safe; A 1 or three-part values are asking for trouble.

Sampling trials

To show each participant a random subset of your trials, use the trialOrder column with a sampling spec:

trialOrder = 1: sample 10

Every tagged row carries the group number; at runtime Testable keeps 10 randomly chosen trials from that group and drops the rest, so each participant sees a different subset. Variants:

• 1: sample 10 difficulty keeps 10 trials per distinct value of your difficulty column, preserving the design’s balance.
• 1: sample 10 difficulty easy samples only the easy trials down to 10 and keeps all others.
• 1: select 10 keeps the same random choice but presents the survivors in trial file order.
• 1: groupSample 2 difficulty keeps all trials of 2 randomly chosen difficulty values and drops the other values entirely.

Beyond sampling, ordering words in the same cell shape the order without dropping trials: limiting how many same-condition trials appear in a row (maxRun), forbidding immediate repeats (noRepeat), forcing alternation, spacing repeats apart, balancing conditions across the session, and more. Specs are checked when you save the trial file, so an impossible design is caught in the editor, never in front of a participant. The full language is documented on the Trial Sequencing page. The legacy random column cannot carry specs and cannot mix with trialOrder in one file; convert a legacy shuffle group 1 to trialOrder = 1: shuffle.

Caution

random and randomBlock decide the trial sequence once per participant, when the experiment loads, after the trial file has been fully expanded: rows generated from stimulus lists, wildcards, and repeats are all in the pool before any shuffling or sampling happens. If logic sends a participant back through earlier rows, they replay in that same order; nothing re-shuffles mid-session.

Stimulus-level randomisation: stimOptions and stimOrder

The columns above reorder whole trials. To reorder the stimuli WITHIN one trial, use one of two columns:

• stimOptions containing the keyword random shuffles the trial’s stimuli freshly every time the trial is shown.
• stimOrder holds constrained ordering specs, drawn once per participant session: random(chunk 2) shuffles consecutive pairs as wholes, random(within screens) shuffles inside each stimScreens screen while the screen structure stays fixed, and random(pin 3@3_5) pins chosen stimuli to exact or bounded positions while the rest shuffle around them.

Whichever you use, scoring follows the content: a stim-referencing key (for example key = stim2) stays correct wherever that stimulus lands, and the arrangement each participant actually saw is recorded in the stimOrder_actual results column. Worked examples: the counterbalanced sides, match to sample, paired presentation, and attentional blink recipes.

Combining randomisation types

The columns work together. A common pattern:

1. Create multiple condition blocks using randomBlock.
2. Within each block, randomise individual trial order using random.
3. Add a trialOrder group with a sample spec to show each participant a manageable subset of a large stimulus set.

Next steps

• Subject Groups and Allocation: assign participants to fixed groups
• Generating Trials from Stimulus Lists: sample from stimulus lists
• Project Flow and Trial Management: breaks, repeats, and rules