SurveyCTO Programming Work Flow
While it is possible to code a SurveyCTO questionnaire in any different way, the time it will take and the quality of final product, depends a lot on how the work is planned. This article outlines an approach common among expereinced SurveyCTO programmers at DIME.
Paper based survey. Test the way questions are asked. The questions are asked in a way that suits the programming, not other way araound. See Questionnaire Design.
Writing pseudo code is a method that all computer scientist use to before starting to write code when they are not exactly sure how all details of that code will be in the end. It is very rare that anyone starting to code a SurveyCTO questionnaire knows how all modules will be coded, so writing pseudo code is the best place to start.
Writing pseudo code is simple to start by describing at a high level what the code will do (often in bullet points) in plain English. After all functions of the code is described at a high level, more details is added. As detail is added the language is also changes from plain English to something that resembles code more and more. Computer scientist very often write pseudo code with pen and paper or on a white board.
The next subsection gives a quick introduction on how to write pseudo code in relation to a SurveyCTO questionnaire.
Listing the modules
The highest level a questionnaire can be described on are the modules. So start by writing a list of the modules in your questionnaire. Write them in the order that you want them to be asked:
|1. Pseudo Code|
Adding groups and repeat groups
The second highest level of detail is adding all the groups and repeat groups that will control the flow of the questionnaire. Some groups are used to change appearances of the questions, and those group does not need to be listed here. The groups important to list here are the groups that are used as skip patterns.
When you add a repeat group or a group used as a skip pattern, also add what will determine the number of repeats or what will cause the group to be skipped. We are still writing pseudo code so it is perfectly fine to write in plain English, although some code is also good.
|2.1 Pseudo Code|
If you look at the pseudo code above, you will see that the repeat in the employment module depends on a variable that is not asked until the household roster. This is the purpose of writing pseudo code. We want to find anything in the intended high level structure of the questionnaire before we have spent any time working on any details. We need to re-write the of our pseudo code to put the employment module after the household roster, and while re-writing we can work restructure more of the detail we already have. For example introducing some variable names, add variables in that are needed in later modules:
|2.2 Pseudo Code|
Keep adding more detail
Keep adding more and more detail and move around sections. There is no clear rule for when a pseudo code is completed, but the point of the exercise is to get an idea of the details that are needed for the flow of the questionnaire. When you have the structure or the "skeleton" of your survey and when you find yourself confident that you have considered most details that can affect your code, then you can move on to actual programming.
The more time you spend on pseudo coding the easier the actual coding will be. Spend at least a few days on this. Maybe not the full day, but write up your first pseudo code and then sleep on it. Review it with fresh eyes the next day. Or even better, when you have a final draft, discuss your pseudo code with someone else in their project. Proofreading pseudo cope works just as a proofreader finds aspects of text that the author of the text have not thought of before
When the pseudo code is completed. SurveyCTO provides template forms that have the basic settings already in place. Always start by using them.
Back to parent topic
This article is a part of the topic Questionnaire Programming.