Difference between revisions of "SurveyCTO Programming Work Flow"

Jump to: navigation, search
Line 67: Line 67:
|}
|}


= Adding more specific references =
== Adding more specific references ==


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:
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:

Revision as of 16:24, 17 January 2017

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.

Read First

  • 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 First

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.

Pseudo Code

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
  • Employment
  • Household Roster
  • Savings
  • Access to Maternal Health

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
  • Employment
    • repeat. One repeat for each household member over the age of 15
  • Household Roster
    • Ask how many people in the household then repeat over that number to ask about name, age etc.
  • Savings
    • Group. Ask if house hold have savings, if so ask savings question
  • Access to Maternal Health
    • Group. If there is a female between the age of 16 and 45, then ask this module to the household head.

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
  • Household Roster
    • Ask how many people in the household then repeat over that number to ask about name, age etc.
  • Employment
    • repeat. One repeat for each household member over the age of 15
  • Savings
    • Group. Ask if house hold have savings, if so ask savings question
  • Access to Maternal Health
    • Group. If there is a female between the age of 16 and 45, then ask this module to the household head.

Adding more specific references

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:

3.1 Pseudo Code
  • Household Roster
    • hh_num_members: Ask how many people in the household
    • Repeat over hh_num_members
      • hhm_name: ask about household members name
      • hhm_age: ask about household members age
      • hhm_sex: ask about household members gender
  • Employment
    • Repeat over hh_num_members
      • Inside repeat, have a group restricted to (hhm_age > 15)
        • inside group, ask about employment
  • Savings
    • savings: Do you have any savings?
    • Group. skip if savings = no
      • savings questions
  • Access to Maternal Health
    • Have a calculate that is yes if any household member is (hhm = female and hhm_age > 15 and hhm_age < 45)
    • Group. Skip this group if the calculated variable above is not yes

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

Template Forms

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.

See also

Further Reading