Actions

Vérifier la logique de l'enquête - Avancé

From LimeSurvey Manual

This page is a translated version of the page Check survey logic - Advanced and the translation is 100% complete.


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])).


Template:Remarque


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


Template:Remarque

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 :

  1. Vert / Bleu clair : une variable qui fait référence à une question plus tôt dans l'enquête 
  2. Bleu : Une fonction
  3. Grey : Une expression de chaîne
  4. Brown : Une expression TOKEN (données du participant)
  5. Black : Opérateur

Éléments à vérifier :

  1. 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.
  2. 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 :

  1. 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.
  2. 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

Voici les captures d'écran de cet exemple.

Il montre la logique de validation de sous-question qui est automatiquement générée lorsque vous utilisez array_filter et array_filter_exclude. Cet exemple montre également comment vous pouvez remplacer la valeur « Autre » personnalisée (la réponse pour Q02_other est Q01_other).



Q05 dans cet exemple montre l'utilisation simultanée de array_filter et array_filter_exclude sur Q01 et Q02, respectivement. Cet exemple illustre les capacités de array_filter en cascade. Notez que l'une des principales raisons d'afficher les critères de « validation » au niveau des questions et des sous-questions est de vous assurer que vous n'avez commis aucune faute de frappe en spécifiant les noms de variable array_filter ou array_filter_exclude (ou si vous utilisez des noms de variable différents pour votre liste de sous-questions filtrées). Si vous avez de telles fautes de frappe, tous les noms de variables non valides apparaîtront en rouge, indiquant qu'ils ne sont pas définis, vous permettant de résoudre rapidement le problème.



Pertinence dynamique

Cet exemple illustre une logique de pertinence en cascade dynamique pour contrôler l'affichage de la visibilité des questions. Vous pouvez télécharger cet exemple ici.

Notez également que les questions ne sont affichées que si certains critères de validation sont respectés. Par exemple, si une personne déclare avoir 2 enfants, certaines questions doivent être remplies par le répondant (kid1 et kid2).


Pertinence au niveau du groupe

Cet exemple montre comment la pertinence au niveau du groupe apparaît dans le contrôle logique. Voici les screenshots de l'exemple décrit ci-dessous.

Comme vous pouvez le voir, l'équation de pertinence au niveau du groupe (cohabs > 1 && p1_rel != "") apparaît dans la ligne grise Personne 2 pour G-2.

Vous remarquerez peut-être également que toutes les questions sont obligatoires. Cependant, si le groupe n’est pas pertinent, toutes ses questions le sont également. Ces questions ne sont donc véritablement obligatoires que si le groupe est pertinent.

Vous remarquerez peut-être également que certaines questions ne s'affichent que si la réponse à la question précédente n'est pas vide. Vous pouvez voir ci-dessous que si p2_sex n'est pas renseigné, p2_name ne sera pas affiché, même s'il s'agit d'une question obligatoire. La question obligatoire p2_age ne sera pas non plus affichée si p2_name n'est pas renseigné. Ces questions peuvent être considérées comme "obligatoires sous condition".

De plus, notez que les messages astuce sont également créés automatiquement pour vous. Ils sont organisés par plage de valeurs (min/max), plage de valeurs de somme (min/max/égal), nombre de réponses (min/max), etc. (cela dépend du type de question utilisé et des attributs actifs). Parfois, vous souhaitez valider une plage de réponses mais vous ne souhaitez pas afficher ce qui peut sembler être des conseils de validation idiots pour l'utilisateur. Dans de tels cas, vous pouvez utiliser l'option de question hide_tip (comme dans ce cas, pour éviter de dire à l'utilisateur que l'âge doit être compris entre 0 et 115 à moins qu'il n'essaye de saisir une mauvaise valeur - voir p2_age ).


Virgule comme séparateur de base (décimal)

Bien que LimeSurvey prenne entièrement en charge l'utilisation de la virgule comme séparateur de base (décimal) au moment de l'exécution, vous devez toujours utiliser une décimale comme séparateur de base au moment de la conception (par exemple, lors de la spécification des valeurs min/max dans les attributs de questions avancés). L'exemple de travail peut être trouvé ici.

N'oubliez pas non plus que la logique validation est créée automatiquement pour vous à partir des attributs de question activés. Les équations peuvent sembler écrasantes, mais vous n’avez pas à vous en préoccuper.