Questionnaire design with DDI – Part 3: What am I doing here?
This is the third in a 5 part series of working with questionnaires and surveys managed using the Data Documentation Initiative XML standard. With DDI being an emerging technology, it is important that users are provided with best practises to ensure that they use the standard in a way that is logical, coherent and most importantly usable and reusable. This series of tutorials and discussions is aimed toward users who have some knowledge of DDI and would like to know how to effectively design markup existing and future questionnaires in DDI.
Part 3 : What am I doing here?
So far in the last two parts of this series we have been looking at how to logically structure questionnaires in DDI. In this post we now switch to looking at how to effectively present DDI sequences in an application and how to structure DDI sequences so they are unambiguous and will display in predictable ways in all viewers.
One of the first difficulties in displayign a DDI Intrument in a webpage is, how many questions to show on a page at anyone time. The easiest, and most appropriate method is to display each sequence as a page and perform logic around those sequences on the server when the users submits data. However, Sequences can contain more than questions, and when we deal with mixed types the it can be difficult to predict how an agent may display the form.
For background. a DDI Sequence is able to reference any ControlConstruct as a child. We are able to separate ControlConstructs into two different types – branches and leaves. In tree data structures branches are able to have as children either other branches or leaves, where as leaves are the ‘end’ of the structure as they cannot have children. In DDI objects “tree-branch ControlConstructs” are objects which cannot reference other ControlConstructs, these are only StatementItem’s and QuestionConstruct’s, and every other ControlConstruct is therefore a ‘tree-branch’.
A Statement item is a way of including headers or textual information in an instrument and QuestionConstruct is a way of including a QuestionItem by reference into an Instrument. Therefore, it is these that are the most vital elements in questionnaire design, with loops and branches adding ‘syntactic sugar’ that improved the form, but don’t gather data directly. Presenting these on a web page is trivially easy, simply just copying the textual nodes of these into a webpage will suffice. In fact, in Ramona these are almost completely hidden from users, with the server using these to determine the next sequence to present for a user, but forever remaining in the background.
The question is though, how should an agent handle a sequence that contains a mix of leaves and branches? Let us work through this example, where we have a mix of leaves and branches, whose types are unimportant:
Sequence id="Seq 1"
leaf reference: L1
branch reference: B2
leaf reference: L3
Here we have two object we know need to be displayed to a user separated by branch that may link to any number of other constructs. In a state-less web context, like Ramona, its going to be hard to come back to this page and make sure the right information is still displayed for the user. So we may decide to show all the leaves we can, and then to the branch and continue on like that, safe in the knowledge that even if the connection to the user fails, we’ll have got all the information in this sequence. However, this effectively reorders the questions in the instrument.
Alternatively, if we are using a desktop application where we have more control over state, it may be possible to present the two leaves and the objects in the branch in the same view. Here we come across an immediate problem: depending on the viewer the user is shown two vastly different forms. The solution is simple: leaves and branches should never be the children of the same parent, and that leaves should always be the child of a DDI Sequence.
This immediate resolves this issue by making the display of objects predictable, when displaying a sequence of leaves the agent only has to display the appropriate text of the statements and questions. When dealing with the logic of loops and branches the agent then can cache this using a format similar to that suggested in Part 2 of this tutorial series Where am I and where do I go next?. This allows the logic and presentation of a survey to be separated completely, making the display of a survey a much more predictable action.
There is an issue with this solution, and that is that it deviates from the structure imposed by DDI making survey design more strict about how elements can be combined. Furthermore, this solution requires designers of surveys understand these restrictions and voluntarily comply with them.
If the standard can’t enforce this restriction, and user can choose not to follow it, is it a good solution? Good, probably not – but it may be the best.
Admittedly, I hold a biased view in this respect. When designing Ramona, I made a decision not to suppose mixed sequences for this two reasons. Firstly, as above it makes the display of sequences more predictable, but secondly it is just plain easier to work with when you can apply these restrictions. When pre-compiling an instrument Ramona will error if it finds a sequence containing mixed types, and for the foreseeable future, when Ramona gets released, even as a research idea, it will continue to hold these restrictions because it prevents users from making ambiguous surveys.
Next up… Questionnaire Design with DDI – Part 4: Can it be done? – A look back at the previous 3 tutorials and an indepth explanation of the realisation of a Ramona – A functional DDI Questionnaire tool.