Vérifier la logique de l'enquête - Avancé
From LimeSurvey Manual
Général
Une option importante qui vous aide à créer et à maintenir facilement des enquêtes complexes est « Vérifier la logique de l'enquête ».
Tout au long du développement et des tests de l'enquête, et avant de l'activer, il est très important de valider la logique de l'enquête. Cela est particulièrement vrai lorsque vous utilisez des équations complexes de pertinence, d'adaptation et de validation : vous devez être sûr que rien ne se brisera lorsque vous exécuterez l'enquête.
Cette fonctionnalité vous permet de valider rapidement l'exactitude de votre enquête, de vos groupes et de vos questions. Il est accessible à partir des options du menu de la barre supérieure situées sous les paramètres liés à l'enquête. Il est disponible via le menu Outils :
Comme vous pouvez le constater ci-dessus, vous pouvez exécuter cette option quatre fois, pour chaque langue utilisée dans une enquête.
Description
L'option « Vérifier la logique de l'enquête » affiche tout ce que vous avez spécifié pour chaque question et groupe (par exemple, nom, texte, aide, conditions/pertinence, règles de validation, valeurs par défaut, sous-questions, réponses) dans un format tabulaire pratique. Il met en évidence les erreurs et vous permet de cliquer sur les ID de question et de groupe (ou les variables utilisées dans les équations) pour ouvrir de nouveaux onglets de navigateur afin de modifier ces questions ou groupes. Cela facilite la modification rapide des erreurs et l'actualisation de la page de vérification logique pour confirmer l'exactitude de l'enquête avant de l'activer.
L'affichage est également conçu pour être lisible par les chercheurs et les promoteurs de l'étude afin qu'ils puissent valider l'exactitude de la conception et de la logique de l'enquête. La vérification de la logique de l'enquête met à jour le cache pour toutes les expressions utilisées dans une enquête active.
Il comprend les colonnes suivantes :
- # - affiche le nombre de séquences de groupes et de questions, en commençant par 0.
- Nom [ ID] - affiche le code de question pour le groupe/question/sous-question. Ces codes peuvent être utilisés comme variables dans expressions. ID est l'identifiant de la question (QID) ou l'identifiant du groupe (GID). Ce champ affiche également le type de question (par exemple, Choix multiple [M])).
- Pertinence [ Validation] (par défaut) - affiche les éléments suivants :
- Pertinence - l'équation de pertinence mise en évidence par la syntaxe pour la question ou le groupe. Si c'est toujours vrai (à afficher dans n'importe quel scénario), la valeur sera 1.
- Validation - ExpressionScript génère automatiquement le validation équation en fonction des attributs de question sélectionnés (par exemple, nombre min/max de réponses, valeurs de somme min/max/égales, valeurs individuelles min/max ou validation d'expression régulière). Cette section montre l'équation de validation générée afin que vous puissiez détecter s'il y a des erreurs (telles que des variables non définies).
- La validation au niveau de la question montre l'équation nécessaire pour vérifier les attributs de la question décrits ci-dessus
- **La validation au niveau de la sous-question montre l'équation nécessaire pour implémenter array_filter, array_filter_exclude et exclusive_option
- Default - si la question a une valeur par défaut, elle est affichée ici, avec une syntaxe mise en évidence (puisque la valeur par défaut pourrait être une expression).
- Texte [ Aide] (Astuce) - affiche ce qui suit :
- Texte - le texte du groupe, de la question, de la sous-question ou de la réponse. Sa syntaxe est mise en surbrillance pour afficher tous les tailoring intégrés, vous permettant ainsi de vérifier que vous avez déclaré toutes les variables que vous prévoyez d'utiliser dans la personnalisation.
- Aide - ceci affiche le texte d'aide pour la question, également mis en évidence par la syntaxe.
- Tip - cela montre l'astuce de validation générée en interne, basée sur les attributs de la question. Ce même conseil est utilisé dans tous les styles d'enquête, ainsi que dans les écrans d'enquête et de saisie de données imprimables.
- Attributs de la question - ceci affiche un tableau de tous les attributs de question pertinents pour cette question. Les attributs qui peuvent être des équations sont mis en évidence par la syntaxe afin que vous puissiez valider leur exactitude.
Les lignes sont codées par couleur comme suit :
- Groupes - sont affichés avec un fond gris clair
- Questions - sont affichés avec un fond vert clair
- ' « Sous-questions » - sont affichées sur un fond jaune pâle !
- » » Réponses » - sont affichées sur un fond blanc uni
Les réponses ont un attribut supplémentaire dans la colonne Pertinence :
- Valeur - il s'agit de la valeur interne par défaut utilisée par les calculs. Si vous utilisez Évaluations, ce sera la valeur de l'évaluation. Sinon, ce sera le même que le nom de la réponse.
Utilisation
En haut de la page, il y a un message récapitulatif. Si tout va bien, il sera indiqué "Aucune erreur de syntaxe détectée dans cette enquête", ou "Ce groupe" ou "Cette question", "en elle-même, ne contient aucune erreur de syntaxe". Si l'inverse est vrai, le message "X questions comportent des erreurs de syntaxe qui doivent être corrigées".
Chaque question comportant des erreurs de syntaxe obtient l'arrière-plan de sa colonne la plus à gauche (c'est-à-dire #) de couleur rouge. De plus, un avertissement indiquant le nombre d'erreurs minimum d'une question sera affiché sous la colonne Nom [ID]. Les erreurs suivantes sont courantes :
- Variable non définie - si vous n'avez pas défini toutes vos variables, ou si vous avez mal saisi array_filter (ou différents ensembles d'options de réponse pour array_filter), alors certaines de vos questions de validation afficheront des erreurs. . Les variables non définies sont affichées en texte rouge, entourées d'une ligne rouge.
- Mauvaise syntaxe - lorsque vous commencez à utiliser des équations de pertinence, vous pouvez utiliser trop ou pas assez de parenthèses. Ces problèmes de syntaxe sont mis en évidence et encadrés en rouge. Si vous passez la souris sur un tel texte encadré en rouge, une info-bulle décrira l'erreur.
Couleurs dans la syntaxe ExpressScript
Les conditions et les équations sont mises en évidence dans la syntaxe pour mieux comprendre ce que vous regardez :
- Vert / Bleu clair : une variable qui fait référence à une question plus tôt dans l'enquête
- Bleu : Une fonction
- Grey : Une expression de chaîne
- Brown : Une expression TOKEN (données du participant)
- Black : Opérateur
Éléments à vérifier :
- Purple : Une variable qui fait référence à un question plus tard dans l’enquête. Il s'agit généralement d'une erreur qui doit être vérifiée.
- Cadre rouge ou rouge : une variable inexistante ou une référence à une question antérieure ou une erreur de syntaxe - doit généralement être vérifiée.
Variables non définies
Si des variables non définies sont utilisées, le nom de la variable respective sera codé en rouge et entouré d'une ligne rouge. Si vous passez votre souris sur le nom de la variable, le message "variable non définie" s'affichera :
Attention : Veuillez noter que LimeSurvey ne permet pas aux administrateurs d'enquête de créer des questions utilisant le même code de question. Cependant, il peut arriver que des codes de question soient similaires dans une enquête si vous importez un groupe de questions ou une question qui utilise le même code de question que l'une de vos questions déjà définies. La question peut toujours être importée car les identifiants de question sont différents. Cependant, si vous souhaitez exporter les résultats de l'enquête pour explorer davantage les survey results (R ou SPSS), soyez prudent car le code de la question est vu comme une variable !
}}
Mauvaise syntaxe
La plupart des erreurs liées aux expressions sont liées à une mauvaise syntaxe. Cela est lié au fait que les administrateurs d'enquête oublient généralement d'ajouter une accolade, d'utiliser correctement les parenthèses, ou qu'ils utilisent les expressions à tort :
Voici de nombreux bons exemples d'utilisation de la syntax highlighting.
JavaScript personnalisé incorrect
Les erreurs JavaScript seront également mises en évidence lors de la vérification de la logique de l'enquête :
Edition et validation accélérées
Tout le texte mis en évidence par la syntaxe comporte des info-bulles intégrées, cliquables :
- Tooltips
- Fonctions - le survol de la souris vous permet de voir l'objectif et la définition de la syntaxe de la fonction ;
- Noms des variables - le survol de la souris vous permet de voir la position (groupe, séquence de questions), le texte de la question et les réponses autorisées pour la question.
- Actions
- Noms de variable - cliquer sur le nom de la variable ouvre une nouvelle fenêtre qui vous permet pour modifier la question. Cela facilite la navigation et la vérification de la logique : continuez simplement à cliquer sur les noms de variables pertinents ou sur les critères de validation de la question pour voir d'où ils viennent et comment ils sont utilisés.
Exemples
Les exemples suivants sont tirés des Enquêtes par sondage ExpressionScript. Vous pouvez trouver des captures d'écran des enquêtes en cours, des explications et des téléchargements sur cette page.
Indice de masse corporelle
Voici les screenshots de cet exemple.
Il s'agit de la vue de réorganisation des questions du calcul de l'indice de masse corporelle. Vous pouvez voir les équations de pertinence pour le poids, la taille et l'IMC dans la colonne « Question » :
Pour un meilleur aperçu de l'enquête, consultez la page de logique de l'enquête :
Cet exemple d'enquête est également un bon exemple d'instructions if() imbriquées pour générer le « weightstatus ».
Logique en cascade
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.
