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.
- Do not start at the top of the survey and work your way through one question at the time. That takes longer time and tend to end up in less well structured questionnaires that are much more error prone. Read all if this article
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, as early as possible, catch anything that will cause a problem while we are still working on a high level, and before we have spent a lot of time working on details. If we first would have spent a week working out the detail of one module, and later figure out that we need to make a change to the structure of the questionnaire, then there is a risk that we have to re-do that work.
|2.2 Pseudo Code|
Adding more specific references
From here on it is a iterative process of adding a few details at the time. Focus on adding repeat groups, groups with skip patterns and any variables that they reference. Also add references such as being able to include labels from previous modules. For example, in the pseudo code below we most likely want to be able to reference the names listed in the household roster in the employment section. We might also want to be able to have all women aged 16-45 listed as answer options in any question in the Access to Maternity Health Care section. Repeat this step and add a bit more detail in each repetition, and each time make sure that the structure still suits what you intend to do.
|3.1 Pseudo Code|
When is Pseudo Code Complete?
There is no clear rule for when a pseudo code is completed, but the more experienced a coder gets the more detail is included in their pseudo code. For a beginner it might be difficult to predict what added detail will require an update to the structure the more detailed it gets. It is possible to take a brake in pseudo coding and code up the structure that you have in the pseudo code already. Do some experimentation to test logic that you are unsure of, and then return back to working on your pseudo code.
The point of pseudo code is to get an idea of the details that are needed for the flow of the questionnaire. When you have your structure (sometimes called "questionnaire skeleton") then you can move on to implementing your pseudo code in actual SurveyCTO code.
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 is just as useful as asking someone to proofread your text documents.
You have now reached the point when you can start coding. If you both have first created a paper survey and written your pseudo code, then you to the best degree possible reduced the risk of running in to time consuming major issues while programming. However, there are often unexpected issues that even the most experienced coders run in to. In those cases it might be helpful to go back to the paper survey or the pseudo code and see if you can come up with a solution that way.
When you start coding, never start with an empty excel sheet. 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.