This paper addresses a number of issues in the development of CAI questionnaires. The linking theme is the importance of having, at least for more complex elements in a questionnaire, a specification that is independent of the instructions needed for its implementation in the chosen package.
A recurrent theme since widespread use of CAI has been the difficulty of representing the content of complex instruments in a generally intelligible form. Automated systems for the documentation of programs can play a useful role, but there is an inherent circularity in a process that is driven by the program itself. Faithfulness to an independent specification is a separate question if the program already embodies a degree of translation from that specification.
What does a specification for a questionnaire consist of? Authors of CAI packages like to hold out the promise that the researcher can implement a questionnaire unaided by technical experts, the instructions in the package being the definitive statement of the requirement. This view is untenable for more complex questionnaires even for an in-house researcher and the client will certainly wish to agree the specification at a higher level of description.
In the specification of question content there is largely a one-to-one correspondence between the elements in a specification as generally understood and the instructions ultimately required by a package. Here it makes sense for the researcher to learn the package syntax to a degree sufficient to state requirements in that form and to view it as the final record of the requirement. An automatically reformatted presentation of the same instructions is also likely to be acceptable to a client.
For other parts of a specification complexity escalates rapidly when users exploit the opportunities afforded by CAI to implement ever more complex instruments. The number and form of program statements necessary to implement some routing or control features may stand in stark contrast to the relative brevity of a researcher’s specification. The latter can be unambiguous yet its translation into the instructions required by the package may still be a significant task. Few researchers, let alone clients, will have desire, time or opportunity to develop the skills needed to assess fully the final form of instructions to the package or any alternative presentation of them that a documentation system may provide. It is important to have a final version of the specification in a form that the client can understand and be willing to ‘sign off’. Ensuring that the working program implements that specification then becomes a separate task of checking and testing.
| Back to: Top | Programme | Page last updated on 31 August, 2003 |