Balanced condition windows

Shuffle trials while keeping the conditions evenly distributed across the whole session, so neither condition clusters early or late.

When to use it

Use this when time-varying influences such as practice, fatigue or drifting strategy could masquerade as a condition effect: a plain shuffle is perfectly happy to front-load one condition, leaving the other over-represented in the tired half of the session. Capping streaks fixes local runs but still allows a slow drift in condition frequency across the session; a windowed balance constraint rules the drift out while keeping the order random. If streaks are the only concern, the constrained condition order recipe with its run cap is the lighter tool.

Trial file

type	content	stimFormat	stim1	condition1	trialOrder	keyboard	key	button1
instructions	Press F if the word is positive and J if it is negative.							NEXT
test		word	SUNNY	positive	1: shuffle; balance 4 condition1	f j	f
test		word	PRIZE	positive	1	f j	f
test		word	SMILE	positive	1	f j	f
test		word	PEACE	positive	1	f j	f
test		word	CRIME	negative	1	f j	j
test		word	STORM	negative	1	f j	j
test		word	GRIEF	negative	1	f j	j
test		word	DEBTS	negative	1	f j	j

How it works

Every test row carries the run tag 1 in trialOrder, so the eight trials form one group, and the first row’s cell holds the program: shuffle randomises the group and balance 4 condition1 constrains which random orders are acceptable. Ordering specs drop nothing; after the shuffle, the group is reordered so that the values of condition1 stay balanced within any window of 4 consecutive trials. With four positive and four negative words, every such window holds two of each, which pins the condition frequency flat from the first trial to the last. Write the spec on the first row of the group only; the other rows take the bare tag 1.

Pick the window so the pool’s proportions fit inside it: with two equally frequent conditions, an even window works, and a window of 4 here means two of each per window. A window the constraint cannot satisfy does not degrade quietly; an ordering error halts the session with an error page instead of running in a bad order, while in preview mode the best order found is kept.

condition1 serves twice: it is the column the balance is computed over, and it is copied into every results row, so the analysis knows each trial’s condition. The instructions row leaves trialOrder empty and stays put as a fixed boundary in front of the shuffled group. keyboard accepts F or J and key scores the valence-appropriate one, lowercase, into the correct results column.

Variations

• Balance a crossed design: in a file that also carries a condition2 column, 1: shuffle; balance 4 condition1*condition2 in trialOrder treats each row’s pair of values as one composite cell and balances the cells within the window; the window then has to hold a whole number of each cell, so an evenly filled 2 x 2 design needs a window of 4 or 8.
• Add a streak cap on top by separating specs with ;, for example 1: shuffle; balance 4 condition1; maxRun 2 condition1 in trialOrder.
• Fix the opening trial as well: append ; first condition1 positive so the block always starts on a positive word.
• Thin a larger pool first: 1: sample 4 condition1; balance 4 condition1 in trialOrder keeps 4 trials per condition, then balances the survivors’ order; sample randomises what it keeps, so it needs no separate shuffle.