Tjek undersøgelseslogik - Avanceret
From LimeSurvey Manual
Generelt
En vigtig mulighed, der hjælper dig med at oprette og nemt vedligeholde komplekse undersøgelser, er Check Survey Logic.
Under hele udviklingen og afprøvningen af undersøgelsen, og før den aktiveres, er det meget vigtigt at validere undersøgelseslogikken. Dette gælder især, når du bruger komplekse relevans-, skræddersy- og valideringsligninger - du skal være sikker på, at intet går i stykker, når du kører undersøgelsen.
Denne funktion lader dig hurtigt validere nøjagtigheden af din undersøgelse, gruppe(r) og spørgsmål. Den kan tilgås fra menuindstillingerne i den øverste bjælke, der er placeret under de undersøgelsesrelaterede indstillinger. Den er tilgængelig via menuen Værktøjer:
Som du kan se ovenfor, kan du køre denne mulighed fire gange for hvert sprog, der bruges i en undersøgelse.
Beskrivelse
Valgmuligheden Kontroller undersøgelseslogik viser alt, hvad du har angivet for hvert spørgsmål og gruppe (f.eks. navn, tekst, hjælp, betingelser/relevans, valideringsregler, standardindstillinger, underspørgsmål, svar) i et praktisk tabelformat. Det fremhæver fejlene og lader dig klikke på spørgsmålet og gruppe-id'erne (eller variabler, der bruges i ligninger) for at åbne nye browserfaner for at redigere disse spørgsmål eller grupper. Dette gør det nemt hurtigt at redigere eventuelle fejl og opdatere logikkontrolsiden for at bekræfte undersøgelsens nøjagtighed, før den aktiveres.
Displayet er også designet til at kunne læses af forskere og studiesponsorer, så de kan validere nøjagtigheden af undersøgelsens design og logik. Kontrol af undersøgelseslogikken opdaterer cachen for alle udtryk, der bruges i en aktiv undersøgelse.
Det inkluderer følgende kolonner:
- # - viser antallet af gruppe- og spørgsmålssekvenser, startende fra 0.
- Navn [ ID] - viser spørgsmålskoden for gruppen/spørgsmålet/underspørgsmålet. Disse koder kan bruges som variable i udtryk. ID er spørgsmåls-id (QID) eller gruppe-id (GID). Dette felt viser også spørgsmålstype (f.eks. Multiple choice [M])).
- Relevans [ Validering] (Standard) - viser følgende:
- Relevans - den syntaks-fremhævede relevansligning for spørgsmålet eller gruppen. Hvis det altid er sandt (skal vises i ethvert scenarie), vil værdien være 1.
- Validation - ExpressionScript genererer automatisk valideringen ligning baseret på de valgte spørgsmålsattributter (f.eks. min/maks. antal svar, min/maks/lig med sumværdier, min/maks individuelle værdier eller validering af regulære udtryk). Dette afsnit viser den genererede valideringsligning, så du kan opdage, om der er fejl (såsom udefinerede variabler).
- Validering på spørgsmålsniveau viser den ligning, der er nødvendig for at verificere de ovenfor beskrevne spørgsmålsattributter
- **Validering på underspørgsmålsniveau viser den ligning, der er nødvendig for at implementere array_filter, array_filter_exclude og exclusive_option
- Standard - hvis spørgsmålet har en standardværdi, vises det her, syntaks-fremhævet (da standarden kunne være et udtryk).
- Tekst [ Hjælp] (Tip) - viser følgende:
- Tekst - teksten til gruppen, spørgsmålet, underspørgsmålet eller svaret. Det er syntaks-fremhævet for at vise enhver indlejret skræddersy, således at du kan bekræfte, at du har erklæret alle de variabler, du planlægger at bruge i skræddersyet.
- Hjælp - dette viser hjælpeteksten til spørgsmålet, også syntaks-fremhævet.
- Tip - dette viser det internt genererede valideringstip, baseret på spørgsmålets attributter. Det samme tip bruges i alle undersøgelsesstile, plus i de udskrivbare undersøgelses- og dataindtastningsskærme.
- Spørgsmålsattributter - dette viser en tabel med alle relevante spørgsmålsattributter for dette spørgsmål. Attributter, der kan være ligninger, er syntaks-fremhævede, så du kan validere deres nøjagtighed.
Rækker er farvekodet som følger:
- Grupper - vises med en lysegrå baggrund
- Spørgsmål - vises med en lysegrøn baggrund
- ' Underspørgsmål' - vises med en lysegul baggrund
- Svar - vises med en almindelig hvid baggrund
Svar har en ekstra egenskab i kolonnen Relevans:
- Værdi - dette er den interne standardværdi, der bruges til beregninger. Hvis du bruger vurderinger, vil dette være vurderingsværdien. Ellers vil dette være det samme som svarets navn.
Brug
Øverst på siden er der en opsummerende besked. Hvis alt er godt, vil der stå "Ingen syntaksfejl fundet i denne undersøgelse", eller "Denne gruppe" eller "Dette spørgsmål", "indeholder i sig selv ingen syntaksfejl". Hvis det modsatte er sandt, vil der stå "X spørgsmål har syntaksfejl, der skal rettes".
Hvert spørgsmål, der har syntaksfejl, får baggrunden for sin kolonne længst til venstre (dvs. #) farvekodet rød. Desuden vil en advarsel, der angiver antallet af minimumsfejl i et spørgsmål, blive vist under kolonnen Navn [ID]. Følgende fejl er almindelige:
- Udefineret variabel - hvis du ikke har defineret alle dine variabler, eller har skrevet forkert array_filter (eller forskellige sæt svarmuligheder for array_filter), så vil nogle af dine valideringsspørgsmål vise fejl . Udefinerede variabler vises i rød tekst, indrammet med en rød linje.
- Dårlig syntaks - når du begynder at bruge relevansligninger, kan du bruge for mange eller for få parenteser. Sådanne syntaksproblemer er fremhævet og indrammet med rødt. Hvis du holder musen over en sådan tekst med røde felter, vil et værktøjstip beskrive fejlen.
Farver i ExpressScript-syntaks
Betingelser og ligninger er syntaksfremhævede for lettere at finde ud af, hvad du ser på:
- Grøn / Lyseblå: En variabel, der refererer til et spørgsmål tidligere i undersøgelsen
- Blå : En funktion
- Grå: Et strengudtryk
- Brun: ET TOKEN-udtryk (deltagerdata)
- Sort: Operator
Ting at tjekke:
- Lilla: En variabel, der refererer til en spørgsmål senere i undersøgelsen. Normalt er dette en fejl og skal kontrolleres.
- Rød eller rød ramme: En ikke-eksisterende variabel eller reference til et tidligere spørgsmål eller en syntaksfejl - skal normalt kontrolleres.
Udefinerede variable
Hvis der anvendes udefinerede variabler, vil det respektive variabelnavn være farvekodet i rødt og omgivet af en rød linje. Hvis du holder musen over variabelnavnet, vil der stå "udefineret variabel":
}}
Dårlig syntaks
De fleste af de udtryksrelaterede fejl er relateret til dårlig syntaks. Dette er relateret til det faktum, at undersøgelsesadministratorer normalt savner at tilføje en krøllet parentes, for at bruge parenteser korrekt, eller de bruger udtryk forkert:
Her er mange gode eksempler på brugen af syntax highlighting.
Dårlig tilpasset JavaScript
JavaScript-fejlene vil også blive fremhævet i undersøgelsens logikcheck:
Hastighedsredigering og validering
Al den syntaks-fremhævede tekst har værktøjstip indlejret, som er klikbare:
- Tooltips
- Functions - ved at holde musen svævende kan du se formålet og syntaksdefinitionen af funktionen;
- Variable Names - svæver du med musen, kan du se positionen (gruppe, spørgsmålssekvens), spørgsmålstekst og tilladte svar på spørgsmålet.
- Actions
- Variable Names - ved at klikke på variabelnavnet åbnes et nyt vindue, der giver dig mulighed for for at redigere spørgsmålet. Dette gør det nemt at navigere og verificere logik - bare fortsæt med at klikke på variabelnavne af relevans eller valideringskriterier for spørgsmålet for at se, hvor de kommer fra, og hvordan de bruges.
Eksempler
De følgende eksempler er taget fra ExpressionScript-eksempelundersøgelserne. Du kan finde skærmbilleder af kørende undersøgelser, forklaringer og downloads på den side.
Kropsmasseindeks
Her er skærmbilleder af dette eksempel.
Dette er spørgsmålet-genbestillingsvisningen af Body Mass Index-beregningen. Du kan se relevansligningerne for vægt, højde og BMI under kolonnen Spørgsmål:
For en bedre undersøgelsesoversigt, tjek undersøgelseslogiksiden:
Dette undersøgelseseksempel er også et godt eksempel på indlejrede if()-sætninger til at generere "vægtstatus".
Cascading logik
Her er skærmbilleder af dette eksempel.
Den viser valideringslogikken for underspørgsmål, der genereres automatisk, når du bruger array_filter og array_filter_exclude. Dette eksempel viser også, hvordan du kan erstatte den skræddersyede "Andet"-værdi (svaret for Q02_other er Q01_other).
Q05 i dette eksempel viser samtidig brug af array_filter og array_filter_exclude på henholdsvis Q01 og Q02. Dette eksempel viser cascading array_filter-egenskaber. Bemærk, at en af hovedårsagerne til at vise spørgsmåls- og underspørgsmålsniveauet validering-kriterier er at hjælpe med at sikre, at du ikke har lavet nogen tastefejl ved at specificere array_filter eller array_filter_exclude variabelnavne (eller hvis du bruger forskellige variabelnavne til din liste over filtrerede underspørgsmål). Hvis du har sådanne tastefejl, vil alle de ugyldige variabelnavne blive vist i rødt, hvilket indikerer, at de er udefinerede, så du hurtigt kan løse problemet.
Dynamisk relevans
Dette eksempel demonstrerer dynamisk kaskaderelevanslogik til at kontrollere visningen af spørgsmålets synlighed. Du kan downloade dette eksempel her.
Bemærk også, at spørgsmål kun vises, hvis visse valideringskriterier er opfyldt. For eksempel, hvis en person angiver, at hun har 2 børn, skal visse spørgsmål udfyldes af respondenten (kid1 og kid2).
Relevans på gruppeniveau
Dette eksempel viser, hvordan relevans på gruppeniveau vises i logikkontrollen. Her er skærmbilleder af eksemplet beskrevet nedenfor.
Som du kan se, vises relevansligningen på gruppeniveau (cohabs > 1 && p1_rel != "") i den grå person 2-række for G-2.
Du kan også bemærke, at alle spørgsmålene er obligatoriske. Men hvis gruppen er irrelevant, så er alle dens spørgsmål også. Som følge heraf er disse spørgsmål kun virkelig obligatoriske, hvis gruppen er relevant.
Du kan også bemærke, at visse spørgsmål kun vises, hvis svaret på det foregående spørgsmål ikke er tomt. Du kan se nedenfor, at hvis p2_sex ikke er udfyldt, vil p2_name ikke blive vist, selvom det er et obligatorisk spørgsmål. Det obligatoriske spørgsmål p2_age vil heller ikke blive vist, hvis p2_name ikke er udfyldt. Disse spørgsmål kan betragtes som "betinget obligatoriske".
Bemærk desuden, at tip-meddelelserne også oprettes automatisk til dig. De er organiseret efter værdiområde (min/maks), sumværdiområde (min/maks/lig med), antal svar (min/maks) osv. (det afhænger af den anvendte spørgsmålstype og aktive attributter). Nogle gange ønsker du at validere et svarområde, men ønsker ikke at vise, hvad der kan se ud til at være dumme valideringstip til brugeren. I sådanne tilfælde kan du bruge spørgsmålsmuligheden hide_tip (som i dette tilfælde for at undgå at fortælle brugeren, at alderen skal være mellem 0 og 115, medmindre de forsøger at indtaste en dårlig værdi - se p2_age ).
Komma som radix (decimal) separator
Selvom LimeSurvey fuldt ud understøtter brugen af komma som radix (decimal) separator ved kørsel, skal du stadig bruge en decimal som radix separator på designtidspunktet (f.eks. når du angiver min/max værdier i avancerede spørgsmål attributter). Arbejdseksemplet kan være findes her.
Husk også, at valideringslogikken oprettes automatisk for dig ud fra de aktiverede spørgsmålsattributter. Ligningerne kan se overvældende ud, men du behøver ikke bekymre dig om dem.