Survey Questionnaires

Here are the last two tips for this series to help you build quick and clean survey questionnaires in mobile survey software.

Include few or no hard coded strings in scripting

In general, scripting should be as compact and clean as possible, and you should avoid putting literal strings in the script.  This is for two reasons:

Literal strings make it extremely cumbersome to run a multilingual survey questionnaires as translations need to be hard-coded as well. Note that scripting is never included in translation files, so any survey translations sent to translators from Entryware will not include these strings

Scripts need to be parsed on each client every time they are run. That means if you include an especially long string in your scripting, the mobile devices will need to parse over it character-by-character. With sufficient strings in scripting, this can result in a noticeable slowdown in performance.

It is often safer and more elegant to use dummy categorical type of questions for these literal strings and text piping to accommodate scripted strings.

Simplify conditions used in multiple questions by using flag variables

Sometimes you have a few “classes” of respondent which are asked very specific questions.  Rather than create multiple copies of projects or questions, common sense tells you to use scripting in the prequestion of relevant questions to skip past if the respondent doesn’t need to answer the question. This is exactly the correct way to program the survey, but there are shortcuts you can use to reduce large numbers of conditional statements in multiple questions by using flag variables to simplify conditions.

A flag variable, in its simplest form, is a variable you define to have one value until some condition is true, in which case you change the variable's value.  It is a variable you can use to control the flow of a function or statement, allowing you to check for certain conditions while your function progresses. The idea is to use the flag variable mainly as a memory of other conditions which the function checks earlier in its execution.

It is easy to see how the amount of scripted logic can snowball when you have multiple preconditions or you need to combine the original logic with additional constraints. By creating a temporary “flag” variable, small bits of logic can be stored and frequently reused.  The best place for this is in the postquestion of the last question that affects the logic. The scripting for each of the relevant questions is, obviously, much simpler.

Take care in using flag variables. They can quickly become overly complex if you create too many or don’t use clear names.  
 
 

Here are two more tips to help you build quick and clean survey questionnaires in mobile survey software.

Use sections to group related questions

Sections are most commonly used to start and end question groups where you want to use rostering or looping, randomization, or rotation (Enterprise-only).  Since sections are never displayed to the user, you can use them sparingly to help you organize groups of questions in your project. 

Avoid using “goto this” on prequestion

The command “goto this” is used to reference the current question.  Using “goto this” is easier and more reusable than referring to an explicit question name. It forces the current question to be reloaded.  This is useful when you are doing additional validation in postquestion scripting. 

You can also use this command in a prequestion script, BUT you must be extremely careful!  If you allow for a scenario where the prequestion goto this always fires, you will send Entryware Mobile into an infinite loop and lock up the device! 
 
More tips next time!

Creating a survey questionnaire in Entryware is easy.  However, it can be incredibly frustrating.  The difference is in how you design your survey questionnaire.  Here are two tips to help you build quick and clean survey questionnaires in mobile survey software.  This will give Entryware programmers a feel of how to use Entryware to quickly build clean survey questionnaires.


Use meaningful, unambiguous question and response names and aliases

If you are working off a prepared script (for example, a provided Word document), it only makes sense to use the same question names as the source document. This aids in communicating changes or problem areas in the survey (be it in the source document or the Entryware project). 

Avoid using especially long or unhelpful question and alias names. Q1, Q2, Q3 are short and to the point, but if you arbitrarily chose these names you will have trouble finding your gender question if you forgot it was called Q94. Likewise, overly wordy names are problematic because they take up a great deal of screen space in both the question list and the script editor.

if  ((Q51_Age.Person1 < 21 ) | ( Q51_Age.Person1 > 40 ) ) & ( Q50_Gender = Male ) )

message “The first person cannot be a male between the ages of 21 and 40”

endif

This example provides a blend of readability and conciseness. The scripting can be read and understood by any reader even if the reader didn’t write the script to begin with. It isn’t so wordy that it scrolls far off the screen.

Use project-level question properties when appropriate

There are many question properties that you want to set for the entire survey questionnaire (e.g. auto advance, minimum responses, turning on or off the tool bar). It is possible to select all of the questions in the survey questionnaire and set them using the Question Properties frame, however this becomes clumsy to set (and change) in very large surveys and opens the very real risk that questions added at the last minute will not have the properties the rest of the survey questionnaire does. 

Project level settings can be done in OnStart or on the prequestion of first the question. Always remember, project level settings override the question properties widow and question level settings script override project level settings.

More tips next time!

Survey research abuse has been going on for a while. The MRA even offers definitions for SUGGING & FRUGGING (selling or fundraising under the guide of research). I've heard MUGGING for Marketing posing as survey questionnaires.

As we start thinking more about mobile market research, are we going to have to coin TUGGING for shady text messages? I couldn’t possibly keep a straight face.

Whatever it's called, every time the brightest minds in survey research find a new way to conduct timely market feedback (and yes, in this case I mean mobile phone surveys), mass marketers seem to find a way to blur the lines in the consumer’s mind between marketing and legitimate survey research.

As if researchers didn’t have enough to worry about with the number of cell-only households skyrocketing.

Consumer groups are already reacting to so-called “premium” text messages. Why the outrage? To borrow a paragraph directly from this news article:

Customers complained that they were charged $16 to $35 a month — up to $200 to $300 in total — for premium text messages even though they:
• Don't remember signing up for them or
• Weren't clearly told they would cost them a certain amount per message — typically $2, but ranging from 50 cents to $5 or
• Were unable to stop the messages from being sent to them.

I’d be mad, too. But perhaps the worst part is how research once again is getting lumped in with other marketing - “Such messages usually include quizzes, surveys, contests, jokes, horoscopes, sports scores and other content…”

Does it bother anyone else that we’re being lumped in with jokes and horoscopes?

On the flip side of the consumer abuse story, the Canadian National Do Not Call list (which excludes marketing research among some other organizations), seems to be working.

Clearly, the implication for researchers is to continue holding ourselves to the highest standards when we conduct survey research, especially as we move in to using more mobile survey software. For now that probably means only contacting people who have opted-in, and even more importantly, making it easy for them to opt out.