This answer line is quite complex to be parsed by the moderator at game speed, due to its length as well as the number of separate clauses, each with their own distinct introductory words. There are many answer lines seen in tournaments that use timed rounds which are significantly more complex than the example above; occasionally, answers are longer than the question itself.ANSWER: Scotland [or Alba; accept Scotch Snap; prompt on United Kingdom or U.K. or Britain, but do not accept or prompt on "England"]
Some tournaments, notably NAQT's newer nationals sets, have chosen to mitigate problems that arise for the moderator by listing these complex answer lines at the front of the packet. This solution, while certainly helpful, has varying degrees of success in practice. The moderator must hold multiple complex answer structures in memory for up to nine or ten minutes. Any answer given by a player must then be reconciled against these structures, often necessitating rereading of the answer line anyway, adding cognitive load for the moderator and slowing the rate of play.
I'd like to discuss ways to increase the readability of the answer lines to make ruling on correctness of complex answer lines simpler, faster, and less error-prone. I have listed two proposals below, in increasing order of invasiveness.
A few notes first:
- This is not a suggestion to change the substantive content of answer lines, merely the way they are presented to the reader.
- I am not implying that these ideas are perfect, just providing them as starting points for a discussion in an attempt to make moderators' jobs easier.
We return to our example from above, artificially reformatted for demonstrative purposes:
Note the line break before the words 'prompt on "England"'. When ruling on an answer given at game speeds, the answer line as written could be prone to an insidious error.ANSWER: Scotland [or Alba; accept Scotch Snap; prompt on United Kingdom or U.K. or Britain, but do not accept or
prompt on "England"]
Suppose a player provides "England" as a response. The moderator, skimming the answer line quickly, may see that phrase and immediately prompt, failing to notice the "do not accept or" preceding it in the answer line. I have made this mistake previously, and surely other moderators have as well.
Additionally, "do not accept or prompt on" is an unnecessarily lengthy phrase.
We can replace the full phrase with "reject". This approach is minimally invasive and provides the benefits of completely avoiding the line break issues in favor of clean yet clear wording which does not risk losing the negation. It also reduces the length of the phrase substantially, making moderator calls faster.
Applying the proposal results in the following slightly more readable answer line:
2. (Harder) Improve iteration through answer clausesANSWER: Scotland [or Alba; accept Scotch Snap; prompt on United Kingdom or U.K. or Britain, reject "England"]
Once more, the example answer line:
A moderator, in the worst case, must read and understand every clause of the answer line before ruling on it. Long lines and non-standard variable length clauses make this either slow or error-prone, particularly in timed rounds. Consider one possible variant on the answer line in which we split it into three separate categories:ANSWER: Scotland [or Alba; accept Scotch Snap; prompt on United Kingdom or U.K. or Britain, but do not accept or prompt on "England"]
This allows the moderator to quickly find the actual answer provided by a player and rule on its correctness. Of course, this format allows for significant flexibility. Each answer possibility could be placed on its own line, though that would seriously increase the amount of paper used for printed questions.ANSWER: Scotland OR Alba OR Scotch Snap
PROMPT: "United Kingdom" OR "U.K." OR "Britain"
This approach is certainly not without its downsides. Some answer lines would likely take more space than they take right now. On packets intended to only be read electronically, this probably doesn't matter much, but could result in more pages per packet for tournaments which use paper (notably HSNCT and the like). However, this approach provides the greatest benefit when answer lines are already very long, and can be applied selectively at editing time to only certain tossups.
The two items I've listed above are just some basic ideas that I've come up with. If you have other suggestions or ideas to improve answer line readability, please help.