Questionnaire Management System¶
Requirements¶
Questionnaire management systems
A review of the functionality available in Blaise 4.5, the Survey Processing System developed by Statistics Netherlands, was made in order to try and guarantee that the fundamental requirements where duly identified.
Data model basics¶
- Field definition
- A field definition includes a field name and a field type that defines valid values. Usually it will have question text. It can have a description to document the field, a field tag, and special attributes.
- Rules
There are four types of rules: routing instructions, edit checks (hard and soft), computations, and layout instructions.
Routing instructions describe the data entry order of the fields and the conditions under which they will be eligible.
For computer-assisted interviewing, the route specifies the order and conditions in which the fields are asked.
Edit checks determine whether a specified statement is true for the values of the fields involved. If it is false, the instruction will generate an error. What will be done with the error depends on the application at hand. Two kinds of edits are supported. The CHECK instruction defines a hard error, something that must be fixed before the form can be considered clean. The SIGNAL instruction defines a soft error, which is a possible problem. It can be suppressed or the values of the involved fields may be changed. A CHECK is the default.
Computations determine proper routes to process fields, carry out complex checks, or derive values.
Layout instructions determine the placement of data entry fields displayed in the Data Entry Program.
Fields¶
A field is the basic element of the data set in Blaise. Fields can have specific types of definitions. Examples of definition types include strings, numbers, or dates. You can create your own user-defined types of fields.
You specify fields in the FIELDS section:
DATAMODEL Commute1 "The National Commuter Survey, first example."
FIELDS
Name "What is your name?" : STRING[20]
Town "In which town do you live?" : STRING[20]
Gender "Are you male or female?" :
(Male, Female)
MarStat "What is your marital status?" :
(NevMarr "Never married",
Married "Married",
Divorced "Divorced",
Widowed "Widowed")
Children "How many children have you given birth to?" : 0..10
Age "What is your age?" : 0..120
In its most simple form, each field definition consists of an identifying name and a specification of the valid values. A longer text between double quotes will usually be inserted between the name and the value definition. This text may serve to state a question, as description, or to document the field.
The example above shows string, numeric and enumerated data variables.
Rules¶
DATAMODEL Commute1 "The National Commuter Survey, first example."
FIELDS
<--see example above-->
RULES
Name
Town
Gender
MarStat
Age
The five fields will be processed in this order. Field names can also be asked, subject to a condition:
IF (Gender = Female) AND (Age > 12) THEN
Children
ENDIF
This means that the field Children will only be processed if the field Gender has the value Female and Age is greater than 12.
Checking¶
Checks are conditions that have to be satisfied. You can state the check in terms of what the correct relationship between fields should be:
MarStat = NevMarr "he/she is too young to be married!"
The specification instructs the system to check whether the field MarStat has the value NevMarr. If not, then the edit is invoked. You can attach text between double quotes to a condition. Such a text will be used as an error message if the condition is not satisfied.
Checks can be subject to conditions:
IF (Age < 15)
"If age of respondent is less than 15" THEN
MarStat = NevMarr
"then he/she is too young to be married!"
ENDIF
The check MarStat = NevMarrwill only be carried out if the field Age has a value less than 15. The application will reject entries in which people younger than 15 years are married.
Blocks¶
The following specification contains two block definitions: the block BPerson and the block BWork:
DATAMODEL Commute2 "The National Commuter Survey, example 2."
BLOCK BPerson "Demographic data of respondent"
FIELDS
<-- see example above -->
RULES
<-- see example above -->
ENDBLOCK
BLOCK BWork "Data about work and commuting"
FIELDS
Working "Do you have a paid job?" : (Yes, No)
Descrip "Short description of your job" : STRING[40]
Distance "What is the distance to your work (in km)?" : 0..300
Travel "How do you travel to your work?" : SET [3] OF
(NoTravel "Do not travel, work at home",
PubTrans "Public bus, tram or metro",
Train "Train",
Car "Car or motor cycle",
Bicycle "Bicycle",
Walk "Walk",
Other "Other means of transportation")
Commuter "Are you a commuter?" : (Yes, No)
RULES
Working
IF Working = Yes THEN
Descrip Distance Travel
ENDIF
IF (Working = Yes) and (Distance > 10) THEN
Commuter := Yes
ELSE
Commuter := No
ENDIF
ENDBLOCK
FIELDS
Person : BPerson
Work : BWork;
RULES
Person
Work
ENDMODEL
A block is like a sub-data model with fields and rules. A block is a special kind of field type. You define a field with the block name as field type:
FIELDS
Person: BPerson
Field tags¶
Questions on paper questionnaires are often identified using numbers. A field tag is specified between parentheses after the field name and before the first text:
FieldName (FieldTag) "Text" / "Description" : FieldType
A field tag may consist of letters and digits, although usually only digits will be used (to represent question numbers). The following example illustrates the use of field tags:
Working (101) "Do you have a paid job?" : (Yes, No)
Descrip (102) "What is your job description" : STRING[40]
Field types¶
String type¶
A string field accepts any text as value, provided the length of the text does not exceed the specified maximum length. An example:
Name "What is your name? " : STRING[30]
You can test the contents of, or make an assignment to, a string field using single quote marks:
IF SectionName = 'Household' THEN
Label1 := 'Household Roster'
ENDIF
It is common to test or assign values between string fields:
IF Name1 <> Name2 THEN
Name1 := Name2
ENDIF
To test for an empty string you can use either the word EMPTY or two single quote marks with no space between them:
IF Name = EMPTY THEN...
IF Name = '' THEN
OPEN type¶
For long, open-ended text responses of variable length you can use the OPEN type. OPEN type fields are useful when the interviewer must record verbatim answers from respondents.
Integer type¶
Integer fields can be defined in several ways:
Age1 "What is your age?" "Age of respondent" : 0..120
Age2 "What is your age?" "Age of respondent" : INTEGER[3]
Decimal or real type¶
To define a field that accepts decimal numbers, you can use the following type declarations:
Ticket1 "How much did you pay for your train ticket?" : 0.00..10.00
Ticket2 "How much did you pay for your train ticket?" : REAL[5, 2]
Ticket3 "How much did you pay for your train ticket?" : REAL[5]
Enumerated type or precode¶
An enumerated field can take as a value one of the items in a list of items. The item is known as a category identifier. A simple example is:
Gender "What is your gender?" : (Male, Female)
Set type¶
To allow a respondent to choose more than one item from a list of answers, use a SET field. A SET field may also be known as a multiple precode or code-all-that-apply. Consider the following example:
Travel "How do you travel to your work?" : SET [3] OF
(NoTravel "Do not travel, work at home",
PubTrans "Public bus, tram or metro",
Train "Train",
Car "Car or motor cycle",
Bicycle "Bicycle",
Walk "Walk",
Other "Other means of transport")
The format is the same as that of an enumerated field with the addition of the reserved words SET [3] OF. This indicates that, at most, three different category values can be selected. By specifying SET OF without a number between brackets, you allow all items to be picked from the list.
Stored values of enumerated and set fields¶
The values in enumerated fields and SET fields are stored as code numbers. The first item in the list is assigned code 1, the second gets code 2, and so on. You can specify your own code numbers to overrule this coding scheme. You do that by adding numbers in parentheses between category names and category texts. Consider the following example:
Travel "How do you travel to your work?" : SET [3] OF
(NoTravel (0) "Do not travel, work at home"
PubTrans "Public bus, tram or metro",
Train "Train",
Car (4) "Car or motorcycle",
Bicycle "Bicycle",
Walk "Walk",
Other (9) "Other means of transport")
This means that NoTravel is coded as 0. Subsequent values are coded in ascending order until a new code is encountered. Here PubTrans is coded as 1 and Train as 2. The codes of the other values are 4 for Car, 5 for Bicycle, 6 for Walk, and 9 for Other.
Date and time type¶
A date field is a special field type that only accepts dates as values. For example:
Birth "What is your date of birth?" : DATETYPE
TimeTravel "At what time do you start work?" : TIMETYPE
Classification type¶
To perform hierarchical coding, a classification type is needed.
Arrayed fields¶
An arrayed field defines a series of fields of the same type.
TYPE section¶
With the TYPE section, you can define reusable type definitions (or just types), then use them in later sections:
TYPE
TTravel = SET [3] OF
(NoTravel "Do not travel, work at home",
PubTrans "Public bus, tram or metro",
Train "Train",
Car "Car or motor cycle",
Bicycle "Bicycle",
Walk "Walk",
Other "Other means of transport")
FIELDS
TravelNow "How do you travel to your work at the moment?" : TTravel
TravelThen "How did you travel to your work one year ago?" : TTravel
RULES
TravelNow
TravelThen
A Block may be considered a FieldType.
Type libraries¶
Survey organisations will find it profitable to standardise the types that are used in two or more surveys. This will make programming quicker and make it easier to compare survey results. Interviewers and data editors will also appreciate the common standards between surveys. Types can be shared by many applications in two different ways.
They can be incorporated with an INCLUDE statement or they can be stored in a pre-compiled type library.
The type library is prepared just like a data model except that the first key word is LIBRARY. A very simple type library:
LIBRARY MyLib
TYPE
TYesNo = (Yes, No)
TMarStat = (Single, Married, Divorced)
ENDLIBRARY
To use the type library from a data model, name the type library in a LIBRARIES section. Then, for any field in the data model, refer to any type in the usual manner. For example:
DATAMODEL UsesLib
LIBRARIES MyLib
FIELDS
WillYou : TYesNo
Married : TMarStat
ENDMODEL
Languages¶
Blaise supports the use of different languages. This is particularly important if you want to interview people speaking different languages. During interviewing, the interviewer can change to a different language with a function key. This requires you to specify the question texts in all languages you might intend to use. The format for a field definition for two languages is as follows:
FieldName "Text1" "Text2" /
"Description1" "Description2" : FieldType
You specify the question texts (Text1 and Text2) in different languages, and specify the descriptions after the slash in the same order. Here is a concrete example:
Name "What is your name?" "Wat is uw naam?" /
"Name of respondent" "Naam van de respondent" : STRING[30]
Enhancing texts¶
Hard spacing and line breaking, font, font size, colour, bold, and underline. Variable text fills. Auxiliary fields (screen labels, etc.)
Routing rules¶
Route field methods¶
Blaise has four methods: CLASSIFY, ASK, SHOW and KEEP. ASK is the default.
- CLASSIFY
- The CLASSIFY routing method puts a classification type field on the route, to show and edit it.
- ASK
- The method ASK shows the field on the screen so the user can enter a value.
- SHOW
- The method SHOW shows the field and its value on the screen. In the FormPane (page), the user will not be able to land on it and will not have the opportunity to change the value. You typically SHOW a field to give information to the user, as with a label in the page. It is possible to use the mouse to land on a show field, but you can not change its value.
- KEEP
- The method KEEP means that the field is not shown on the screen. The user will not be aware that this field exists. The value of the field will be stored in the Blaise data file if the field is defined in the FIELDS section, but the KEEP is considered to be at the end of the RULES section.
If you SHOW or KEEP a field, its value must be computed. If a field is computed but otherwise not mentioned in the RULES, the KEEP method will automatically be applied at the point of computation.
Preventing return to some questions¶
You can use the KEEP method to prevent users from returning to some questions after they have been answered. This is called a wall. This might be done for reasons of confidentiality.