Kontroller undersøkelseslogikk - avansert

Generelt

Et viktig alternativ som hjelper deg med å opprette og enkelt vedlikeholde komplekse undersøkelser, er Kontroller undersøkelseslogikk.

Under utvikling og testing av undersøkelsen, og før du aktiverer den, er det svært viktig å validere undersøkelseslogikken. Dette gjelder spesielt når du bruker komplekse relevans-, tilpasnings- og valideringsligninger - du må være sikker på at ingenting går i stykker når undersøkelsen kjøres.

Med denne funksjonen kan du raskt validere at undersøkelsen, gruppene og spørsmålene er korrekte. Du finner den i menyalternativene i topplinjen, under innstillingene for undersøkelsen. Den er tilgjengelig via menyen Verktøy:

Som du ser ovenfor, kan du kjøre dette alternativet fire ganger, én gang for hvert språk som brukes i en undersøkelse.

Beskrivelse

Alternativet Kontroller undersøkelseslogikk viser alt du har angitt for hvert spørsmål og hver gruppe (f.eks. navn, tekst, hjelp, betingelser/relevans, valideringsregler, standardverdier, underspørsmål, svar) i et oversiktlig tabellformat. Det fremhever feilene og lar deg klikke på spørsmåls- og gruppe-ID-er (eller variabler brukt i ligninger) for å åpne nye nettleserfaner der du kan redigere disse spørsmålene eller gruppene. Dette gjør det enkelt å raskt rette feil og oppdatere siden for logikkontroll for å bekrefte at undersøkelsen er korrekt før du aktiverer den.

Visningen er også laget for å være lesbar for forskere og oppdragsgivere, slik at de kan validere at undersøkelsens utforming og logikk er korrekt. Når du kontrollerer undersøkelseslogikken, oppdateres hurtigbufferen for alle uttrykk som brukes i en aktiv undersøkelse.

Den inneholder følgende kolonner:

• # - viser antall i rekkefølgen av grupper og spørsmål, med start fra 0.

• Navn [ID] - viser spørsmålskoden for gruppen/spørsmålet/underspørsmålet. Disse kodene kan brukes som variabler i uttrykk. ID er spørsmåls-ID (QID) eller gruppe-ID (GID). Dette feltet viser også spørsmålstypen (f.eks. Flervalg [M]).

Hvis du vil vite mer om hvilke variabler som kan brukes i uttrykk, kan du lese følgende wiki-underavsnitt.

• Relevans [Validering] (Standard) - viser følgende:
  • Relevans - den syntaksutheva relevanseligningen for spørsmålet eller gruppen. Hvis den alltid er sann (vises i alle scenarioer), er verdien 1.
  • Validering - ExpressionScript genererer automatisk valideringsligningen basert på de valgte spørsmålsattributtene (f.eks. min./maks. antall svar, min./maks./lik sumverdier, min./maks. enkeltverdier eller validering med regulært uttrykk). Denne delen viser den genererte valideringsligningen, slik at du kan oppdage eventuelle feil (for eksempel udefinerte variabler).
    • Validering på spørsmålsnivå viser ligningen som kreves for å kontrollere spørsmålsattributtene beskrevet ovenfor
    • Validering på underspørsmålsnivå viser ligningen som kreves for å implementere array_filter, array_filter_exclude og exclusive_option
  • Standard - hvis spørsmålet har en standardverdi, vises den her, syntaksutheva (siden standardverdien kan være et uttrykk).

• Tekst [hjelp] (tips) - viser følgende:
  • Tekst - teksten til gruppen, spørsmålet, underspørsmålet eller svaret. Den er syntaksutheva for å vise eventuell innebygd tilpasning, slik at du kan kontrollere at du har deklarert alle variablene du planlegger å bruke i tilpasningen.
  • Hjelp - viser hjelpeteksten for spørsmålet, også den syntaksutheva.
  • Tips - viser det internt genererte valideringstipset, basert på spørsmålsattributtene. Det samme tipset brukes i alle undersøkelsesstiler, samt i den utskriftsvennlige undersøkelsen og i skjermbildene for dataregistrering.
  • Spørsmålsattributter - viser en tabell med alle relevante spørsmålsattributter for dette spørsmålet. Attributter som kan være ligninger, er syntaksutheva slik at du kan validere at de er korrekte.

Radene er fargekodet som følger:

• Grupper - vises med lysegrå bakgrunn
• Spørsmål - vises med lysegrønn bakgrunn
• Underspørsmål - vises med blekgul bakgrunn
• Svar - vises med helt hvit bakgrunn

Svar har en ekstra attributt i kolonnen Relevanse:

• Verdi - dette er standard intern verdi som brukes i beregninger. Hvis du bruker vurderinger, blir dette vurderingsverdien. Ellers er den den samme som svarnavnet.

Beskrivelsen av undersøkelsen, velkomst- og sluttmeldinger, URL etter fullføring, merknad om vilkår og etikett vises i kontrollen av undersøkelseslogikk (over tabellen) hvis de tilhørende feltene ikke er tomme!

Bruk

Øverst på siden vises en sammendragsmelding. Hvis alt er i orden, står det «Ingen syntaksfeil ble funnet i undersøkelsen», eller «Denne gruppen» eller «Dette spørsmålet» «inneholder i seg selv ingen syntaksfeil». Hvis det motsatte er tilfellet, står det «X spørsmål har syntaksfeil som må rettes».

Hvert spørsmål som har syntaksfeil, får bakgrunnen i kolonnen lengst til venstre (dvs. #) fargekodet rød. I tillegg vises en advarsel som angir minste antall feil for et spørsmål under kolonnen Navn [ID]. Følgende feil er vanlige:

• Udefinert variabel - hvis du ikke har definert alle variablene dine, eller har skrevet array_filter feil (eller har ulike sett med svaralternativer for array_filter), vil noen av valideringsspørsmålene dine vise feil. Udefinerte variabler vises med rød tekst, omgitt av en rød linje.

• Feil syntaks - når du begynner å bruke relevanseligninger, kan du bruke for mange eller for få parenteser. Slike syntaksproblemer utheves og omgis av rødt. Hvis du holder musepekeren over slik tekst i rød ramme, beskriver et verktøytips feilen.

Farger i ExpressionScript-syntaks

Betingelser og ligninger er syntaksutheva for at det skal bli lettere å se hva du ser på:

1. Grønn / lyseblå: En variabel som refererer til et spørsmål tidligere i undersøkelsen
2. Blå: En funksjon
3. Grå: Et strenguttrykk
4. Brun: Et TOKEN-uttrykk (deltakerdata)
5. Svart: Operator

Ting å kontrollere:

1. Lilla: En variabel som refererer til et spørsmål senere i undersøkelsen. Dette er vanligvis en feil og bør kontrolleres.
2. Rød eller rød ramme: En ikke-eksisterende variabel eller referanse til et tidligere spørsmål, eller en syntaksfeil - bør vanligvis kontrolleres.

Udefinerte variabler

Hvis det brukes udefinerte variabler, blir det aktuelle variabelnavnet fargekodet rødt og omgitt av en rød linje. Hvis du holder musepekeren over variabelnavnet, står det «undefined variable»:

  Merk at LimeSurvey ikke lar administratorer av undersøkelser opprette spørsmål som bruker samme spørsmålskode. Det kan likevel hende at det finnes like spørsmålskoder i en undersøkelse hvis du importerer en spørsmålsgruppe eller et spørsmål som bruker samme spørsmålskode som et av spørsmålene du allerede har definert. Spørsmålet kan fortsatt importeres fordi spørsmåls-ID-ene er forskjellige. Hvis du imidlertid vil eksportere undersøkelsesresultatene for å utforske dem videre (R eller SPSS), må du være forsiktig, fordi spørsmålskoden oppfattes som en variabel!

}}

Ugyldig syntaks

De fleste feil knyttet til uttrykk skyldes ugyldig syntaks. Det henger sammen med at administratorer av undersøkelser ofte glemmer å legge til en krøllparentes, ikke bruker parenteser riktig, eller bruker uttrykk feil:

Her finner du mange gode eksempler på bruk av syntaksutheving.

Ugyldig tilpasset JavaScript

JavaScript-feil blir også utheved i kontrollen av undersøkelseslogikken:

Raskere redigering og validering

All tekst med syntaksutheving har innebygde verktøytips, som også kan klikkes på:

1. Verktøytips
   • Funksjoner - når du holder musepekeren over, ser du formålet med funksjonen og definisjonen av syntaksen;
   • Variabelnavn - når du holder musepekeren over, ser du posisjonen (gruppe, rekkefølge for spørsmål), spørsmålstekst og tillatte svar for spørsmålet.
2. Handlinger
   • Variabelnavn - hvis du klikker på variabelnavnet, åpnes et nytt vindu der du kan redigere spørsmålet. Dette gjør det enkelt å navigere i og kontrollere logikken - klikk deg videre på variabelnavn i relevans- eller valideringskriteriene for spørsmålet for å se hvor de kommer fra og hvordan de brukes.

Eksempler

Følgende eksempler er hentet fra eksempelundersøkelsene for ExpressionScript. På den siden finner du skjermbilder av kjørende undersøkelser, forklaringer og nedlastinger.

Kroppsmasseindeks

Her er skjermbilder av dette eksempelet.

Dette er visningen for å endre rekkefølge på spørsmål i beregningen av kroppsmasseindeks. Du kan se relevansuttrykkene for vekt, høyde og KMI under kolonnen Spørsmål:

For en bedre oversikt over undersøkelsen kan du se på siden for undersøkelseslogikk:

Denne undersøkelsen er også et godt eksempel på nestede if()-setninger for å generere "weightstatus".

Kaskaderende logikk

Her er skjermbilder av dette eksempelet.

Det viser valideringslogikken for underspørsmål som genereres automatisk når du bruker array_filter og array_filter_exclude. Eksempelet viser også hvordan du kan erstatte den tilpassede verdien for "Annet" (svaret for Q02_other er Q01_other).

Q05 i dette eksempelet viser samtidig bruk av array_filter og array_filter_exclude på henholdsvis Q01 og Q02. Eksempelet demonstrerer mulighetene for kaskaderende array_filter. Merk at en av hovedgrunnene til at kriteriene for validering på spørsmåls- og underspørsmålsnivå vises, er å hjelpe deg med å sikre at du ikke har gjort skrivefeil i navnene på variablene for array_filter eller array_filter_exclude (eller hvis du bruker andre variabelnavn for listen over filtrerte underspørsmål). Hvis du har slike skrivefeil, vises alle ugyldige variabelnavn i rødt for å vise at de er udefinerte, slik at du raskt kan rette feilen.

Dynamisk relevans

Dette eksempelet demonstrerer dynamisk, kaskaderende relevanslogikk for å styre om spørsmål vises. Du kan laste ned eksempelet her.

Merk også at spørsmål bare vises hvis bestemte valideringskriterier er oppfylt. Hvis en person for eksempel oppgir at hun har 2 barn, må respondenten fylle ut visse spørsmål (kid1 og kid2).

Relevans på gruppenivå

Dette eksempelet viser hvordan relevans på gruppenivå vises i logikksjekken. Her er skjermbilder av eksempelet som beskrives nedenfor.

Som du ser, vises relevanseligningen på gruppenivå (cohabs > 1 && p1_rel != "") i den grå raden Person 2 for G-2.

Du kan også legge merke til at alle spørsmålene er obligatoriske. Hvis gruppen er irrelevant, er imidlertid alle spørsmålene i den det også. Dermed er disse spørsmålene bare reelt obligatoriske dersom gruppen er relevant.

Du kan også merke deg at enkelte spørsmål bare vises hvis svaret på forrige spørsmål ikke er tomt. Som du ser nedenfor, vil p2_name ikke vises hvis p2_sex ikke er fylt ut, selv om det er et obligatorisk spørsmål. Det obligatoriske spørsmålet p2_age vises heller ikke hvis p2_name ikke er fylt ut. Disse spørsmålene kan regnes som «betinget obligatoriske».

Vær også oppmerksom på at tips-meldingene opprettes automatisk for deg. De er organisert etter verdiområde (min/maks), verdiområde for sum (min/maks/lik), antall svar (min/maks) osv. (avhengig av spørsmålstypen som brukes og aktive attributter). Noen ganger vil du validere et svarområde, men ikke vise valideringstips som kan virke overflødige for brukeren. I slike tilfeller kan du bruke spørsmålsalternativet hide_tip (som her, for å unngå å fortelle brukeren at alderen må være mellom 0 og 115 før vedkommende prøver å oppgi en ugyldig verdi – se p2_age).

Komma som desimalskilletegn

Selv om LimeSurvey fullt ut støtter bruk av komma som desimalskilletegn når undersøkelsen kjøres, må du fortsatt bruke punktum som desimalskilletegn under utformingen (for eksempel når du angir min/maks-verdier i avanserte spørsmålsattributter). Det fungerende eksempelet finner du her.

Husk også at valideringslogikken opprettes automatisk for deg ut fra de aktiverte spørsmålsattributtene. Ligningene kan se overveldende ut, men du trenger ikke bekymre deg for dem.