Check survey logic - Advanced/bg

Общо

Важна опция, която ви помага да създавате и лесно да поддържате сложни анкети, е Проверете логиката на анкетата.

По време на разработката и тестването на проучването и преди активирането му е много важно да потвърдите логиката на проучването. Това е особено вярно, когато използвате сложни уравнения за уместност, приспособяване и валидиране - трябва да сте сигурни, че нищо няма да се повреди, когато стартирате проучването.

Тази функция ви позволява бързо да потвърдите точността на вашето проучване, група(и) и въпрос(и). Може да бъде достъпен от опциите на менюто в горната лента, намиращи се под настройките, свързани с проучването. Достъпен е от менюто Инструменти:

Файл:show_logic_file.jpg

Както можете да видите по-горе, можете да стартирате тази опция четири пъти за всеки език, използван в проучването.

Описание

Опцията Провери логиката на анкетата показва всичко, което сте посочили за всеки въпрос и група (напр. име, текст, помощ, условия/уместност, правила за валидиране, настройки по подразбиране, подвъпроси, отговори) в удобен табличен формат. Той подчертава грешките и ви позволява да щракнете върху идентификаторите на въпроса и групата (или променливите, използвани в уравненията), за да отворите нови раздели на браузъра, за да редактирате тези въпроси или групи. Това улеснява бързото редактиране на всякакви грешки и опресняването на страницата за логическа проверка, за да потвърдите точността на проучването, преди да го активирате.

Дисплеят също така е проектиран да бъде четлив от изследователи и спонсори на изследването, така че те да могат да потвърдят точността на дизайна и логиката на проучването. Проверката на логиката на проучването актуализира кеша за всички изрази, използвани в рамките на активно проучване.

Той включва следните колони:

• # - показва броя на последователностите от групи и въпроси, като се започне от 0.

• Име [ ID]' - показва кода на въпроса за групата/въпроса/подвъпроса. Тези кодове могат да се използват като променливи в изрази. ID е идентификаторът на въпроса (QID) или идентификаторът на групата (GID). Това поле също показва типа на въпроса (напр. Множествен избор [M])).

Template:Забележка

• ''Уместност [ Validation] (По подразбиране) - показва следното:
  • Relevance - маркираното в синтаксиса уравнение за релевантност за въпроса или групата. Ако винаги е вярно (да се показва във всеки сценарий), стойността ще бъде 1.
  • Проверка - ExpressionScript автоматично генерира валидация уравнение въз основа на избраните атрибути на въпроса (напр. минимален/максимален брой отговори, минимални/максимални/равни сумарни стойности, минимални/максимални индивидуални стойности или валидиране на регулярен израз). Този раздел показва генерираното уравнение за валидиране, така че да можете да откриете дали има някакви грешки (като недефинирани променливи).
    • Валидирането на ниво въпрос показва уравнението, необходимо за проверка на описаните по-горе атрибути на въпрос
• **Проверката на ниво подвъпрос показва уравнението, необходимо за прилагане на array_filter, array_filter_exclude и exclusive_option
  • Default - ако въпросът има стойност по подразбиране, той се показва тук, синтаксисно маркиран (тъй като по подразбиране може да бъде израз).

• 'Текст [ Помощ] (Съвет) - показва следното:
  • Текст - текстът на групата, въпроса, подвъпроса или отговора. Той е синтаксисно подчертан, за да покаже всички вградени tailoring, като по този начин ви позволява да проверите дали сте декларирали всички променливи, които планирате да използвате в приспособяването.
  • Помощ - това показва помощния текст за въпроса, също маркиран със синтаксис.
  • Съвет - това показва вътрешно генерирания съвет за валидиране, въз основа на атрибутите на въпроса. Същият този съвет се използва във всички стилове на анкета, плюс в екраните за анкета за печат и въвеждане на данни.
  • „Атрибути на въпроса“ – това показва таблица с всички подходящи атрибути на въпроса за този въпрос. Атрибутите, които може да са уравнения, са синтаксисно маркирани, за да можете да потвърдите тяхната точност.

Редовете са цветно кодирани, както следва:

• Групи - показани са на светлосив фон
• Въпроси - показани са на светлозелен фон
• ' Подвъпроси - показани са на бледожълт фон
• Отговори - показани са на обикновен бял фон

Отговорите имат допълнителен атрибут в колоната Уместност:

• Value - това е вътрешната стойност по подразбиране, използвана от изчисленията. Ако използвате Оценки, това ще бъде стойността на оценката. В противен случай това ще бъде същото като името на отговора.

Template:Забележка

Използване

В горната част на страницата има обобщено съобщение. Ако всичко е наред, ще пише „Няма открити синтактични грешки в това проучване“, или „Тази група“ или „Този въпрос“, „сам по себе си не съдържа никакви синтактични грешки“. Ако е вярно обратното, ще се каже „Х въпроси имат синтактични грешки, които трябва да бъдат коригирани“.

Всеки въпрос, който има синтактични грешки, получава фона на най-лявата си колона (т.е. #) с червен цвят. Също така, предупреждение, посочващо броя на минималните грешки на даден въпрос, ще бъде показано под колоната Име [ID]. Следните грешки са често срещани:

• Undefined variable - ако не сте дефинирали всичките си променливи или сте въвели грешно array_filter (или различни набори от опции за отговор за array_filter), тогава някои от вашите въпроси за валидиране ще показват грешки . Недефинираните променливи са показани в червен текст, оградени с червена линия.

• Лош синтаксис - когато започнете да използвате уравнения за релевантност, може да използвате твърде много или твърде малко скоби. Такива синтактични проблеми са маркирани и оградени в червено. Ако задържите курсора на мишката върху такъв текст в червено поле, подсказка ще опише грешката.

Цветове в синтаксиса на ExpressScript

Условията и уравненията са синтаксисно маркирани, за да разберете по-лесно какво гледате:

1. Зелено / Светло синьо: Променлива, която препраща към въпрос по-рано в анкетата
2. Син : Функция
3. Сиво: Низов израз
4. Кафяв: TOKEN израз (данни за участници)
5. Черно: Оператор

Неща за проверка:

1. Лилаво: Променлива, която препраща към въпрос по-късно в анкетата. Обикновено това е грешка и трябва да се провери.
2. Червена или червена рамка: Несъществуваща променлива или препратка към по-ранен въпрос или синтактична грешка - обикновено трябва да се провери.

Недефинирани променливи

If undefined variables are used, the respective variable name will be color-coded in red and surrounded by a red line. If you hover your mouse over the variable name, it will say "undefined variable":

  Please note that LimeSurvey does not allow survey administrators to create questions that use the same question code. However, it could happen to have similar question codes within a survey if you import a question group or a question that uses the same question code as one of your already-defined questions. The question can still be imported because the question ids are different. However, if you wish to export the survey results to further explore the survey results (R or SPSS), be careful because the question code is seen as a variable!

}}

Bad syntax

Most of the expression-related mistakes are related to bad syntax. This is related to the fact that survey administrators usually miss to add a curly bracket, to properly make use of parentheses, or they use expressions wrongly:

Here are many good examples on the usage of syntax highlighting.

Bad custom JavaScript

The JavaScript errors will also be highlighted in the survey logic check:

Speeding editing and validation

All of the syntax-highlighted text has tooltips embedded, which are clickable:

1. Tooltips
   • Functions - hovering the mouse lets you see the purpose and syntax definition of the function;
   • Variable Names - hovering the mouse lets you see the position (group, question sequence), question text, and allowable answers for the question.
2. Actions
   • Variable Names - clicking on the variable name opens a new window that allows you to edit the question. This makes it easy to navigate and verify logic - simply keep clicking on variable names of relevance or validation criteria for the question to see where they come from and how they are used.

Examples

The following examples are taken from the ExpressionScript sample surveys. You can find screenshots of running surveys, explanations, and downloads on that page.

Body Mass Index

Here are screenshots of this example.

This is the question-reorder view of the Body Mass Index calculation. You can see the relevance equations for weight, height, and BMI under the Question column:

For a better survey overview, check the survey logic page:

This survey example is also a good example of nested if() statements to generate the "weightstatus".

Cascading logic

Here are screenshots of this example.

It shows the subquestion validation logic that is automatically generated when you use array_filter and array_filter_exclude. This example also shows how you can substitute the tailored "Other" value (the answer for Q02_other is Q01_other).

Q05 in this example shows simultaneous use of array_filter and array_filter_exclude on Q01 and Q02, respectively. This example demonstrates cascading array_filter capabilities. Note that one of the main reasons for showing the question and subquestion level validation criteria is to help ensure you have not made any typos in specifying the array_filter or array_filter_exclude variable names (or in case you use different variable names for your list of filtered subquestions). If you have such typos, all the invalid variable names will appear in red indicating that they are undefined, letting you quickly fix the problem.

Dynamic relevance

This example demonstrates dynamic cascading relevance logic to control display of question visibility. You can download this example here.

Also note that questions are displayed only if certain validation criteria are met. For example, if a person states that she has 2 kids, certain questions have to be filled in by the respondent (kid1 and kid2).

Group-level relevance

This example shows how group-level relevance appears in the logic check. Here are screenshots of the example described below.

As you can see, the group-level relevance equation (cohabs > 1 && p1_rel != "") appear in the grey Person 2 row for G-2.

You may also notice that all of the questions are mandatory. However, if the group is irrelevant, so are all its questions. As a result, those questions are only truly mandatory if the group is relevant.

You may also note that certain questions are displayed only if the answer to the previous question is not empty. You may see below that if p2_sex is not filled in, p2_name is not going to be displayed, even though it is a mandatory questions. The mandatory question p2_age is also not going to be displayed if p2_name is not filled in. These questions can be considered "conditionally mandatory".

Additionally, note that the tip messages are also automatically created for you. They are organized by value range (min/max), sum value range (min/max/equals), number of answers (min/max), etc (it depends on the used question type and active attributes). Sometimes you want to validate an answer range but don't want to display what might appear to be silly validation tips to the user. In such cases, you can use the hide_tip question option (as in this case, to avoid telling the user that the age must be between 0 and 115 unless they try to enter a bad value - see p2_age).

Comma as radix (decimal) separator

Although LimeSurvey fully supports the use of comma as radix (decimal) separator at run-time, you must still use a decimal as the radix separator at the design-time (e.g., when specifying min/max values in advanced question attributes). The working example can be found here.

Also, remember that the validation logic is created for you automatically from the enabled question attributes. The equations may look overwhelming, but you don't need to worry about them.