Counterbalanced key mapping

Give half the participants one response-key mapping and half the reversed mapping, with matching instructions for each.

When to use it

Use this whenever a two-key task could confound the effect of interest with the keys themselves: dominant hands, left-right biases and keyboard quirks all favour one key, so a fixed mapping bakes that bias into every condition difference. Counterbalancing the mapping across participants cancels it out. Running two separate projects splits recruitment and analysis for no gain; one file with subjectGroup handles the split and records who got which mapping. If the two groups should differ in what they see rather than how they respond, that is the plain between-subject conditions recipe instead.

Trial file

type	stimFormat	title	content	stim1	subjectGroup	random	keyboard	key	button1
instructions		Animal or object?	You will see words one at a time. Press F if the word names an animal and J if it does not.		1				NEXT
instructions		Animal or object?	You will see words one at a time. Press J if the word names an animal and F if it does not.		2				NEXT
test	word			HORSE	1	1	f j	f
test	word			SPOON	1	1	f j	j
test	word			TIGER	1	1	f j	f
test	word			CHAIR	1	1	f j	j
test	word			HORSE	2	1	f j	j
test	word			SPOON	2	1	f j	f
test	word			TIGER	2	1	f j	j
test	word			CHAIR	2	1	f j	f

How it works

subjectGroup does the assignment: each session the participant is allocated subgroup 1 or 2 (randomly by default, or evenly across participants when the project’s even-allocation setting is on) and sees only the rows tagged with that subgroup plus any untagged rows. The trial rows exist twice, once per group, with identical stimuli and identical keyboard cells; only key flips, so the F-for-animal group and the J-for-animal group are scored against their own mapping and the correct results column is comparable across groups. Each group also gets its own instructions row, tagged like the trial rows, so nobody reads the wrong mapping.

All eight test rows carry the run tag 1 in random, so they shuffle as one run; group allocation runs after the shuffle, leaving each participant their four rows in a fresh random order. The instructions rows leave random empty and keep their place at the front. Because their keyboard cells are empty, each instructions screen shows its own NEXT button.

Keep the key values lowercase: keyboard responses are recorded as lowercase tokens, and a key that matches the response only after ignoring case is recorded as unscored rather than incorrect. And use bare integers consistently in subjectGroup: mixing them with named label:N values makes the bare integers’ group depend on the shuffled order, and a bare word like A silently creates no group at all. The allocated subgroup is saved to the results as a subjectGroup info column (1 or 2), which is your mapping label at analysis time.

Variations

• Balance the split exactly: turn on the project’s even-allocation setting so subjectGroup assigns each new participant the least-filled subgroup instead of a random one.
• Cross the key mapping with a second counterbalanced factor by switching to named groups in subjectGroup (mapping:1/mapping:2 on these rows, order:1/order:2 on others); one subgroup is picked per label, and the results record something like mapping:1 order:2. Use the named form everywhere or the bare form everywhere, never both.
• Extend to four counterbalancing lists by tagging rows 1 to 4 in subjectGroup, one row set per mapping.
• Remind participants of their mapping mid-task with a group-tagged break row; break rows are filtered by subjectGroup exactly like trial rows.