Fane-separeret værdiundersøgelsesstruktur

Tab-separeret værdi import og eksport af undersøgelsesstruktur

Denne funktion er designet til at gøre det nemt at bruge et regnearkssoftware som LibreOffice, Excel eller Google Docs til at skrive og redigere undersøgelser. Det eliminerer fuldstændigt afhængigheden af SGQA-koder.

Denne funktion understøtter import fra ASCII- eller UTF-8-kodede Tab Separated Value-filer (TSV) med filtypenavnet .txt.

Template:Bemærk

Kom godt i gang

Den nemmeste måde er at tage en eksisterende undersøgelse og eksportere den i Tab Separated Value-format. Brug den normale eksportundersøgelsesknap, og i stedet for at vælge .lss-format, vælg "Tab Separated Values format (*.txt)". Den vil blive gemt som en tab-separeret værdi-fil i det korrekte format (tabulator-separeret unicode-fil) med alle de korrekte kolonneoverskrifter.

Enhver regnearkssoftware, der understøtter tabulatorseparerede værdier, er i orden (f.eks. OpenOffice eller LibreOffice). LimeSurvey ignorerer enhver formatering i regnearket, men du er velkommen til at tilføje nogle, hvis det hjælper dig.

Bemærk, at den eksporterede fil er i UTF-8-format med Byte Order Mark (BOM) som de første tre (skjulte) tegn. Hvis du dobbeltklikker på .txt og prøver at åbne den direkte med Excel, åbnes den ikke korrekt, fordi Excel ikke er klar over, at den er UTF-8 formateret. For at åbne disse filer med Excel skal du først åbne Excel, derefter vælge Filer: Åbn, vælge .txt-filen og fortælle Excel, at den bruger UTF-8-kodning.

Der vil være en række for hver gruppe, spørgsmål, underspørgsmål og svar. Der er også rækker for globale undersøgelsesvariabler og for sprogspecifikke undersøgelsesvariabler. Det primære sprog vil blive vist først, efterfulgt af eventuelle sekundære sprog. Så hvis der er flere sprog, vil hele indholdet af basissproget vises først (f.eks. alle grupper, spørgsmål, underspørgsmål og svar). Dette vil blive efterfulgt af en oversat kopi for hvert sekundært sprog (med nøjagtig samme nummer og rækkefølge eller rækker for det oversatte sæt).

Relationer udledes af nærhed. Så spørgsmål efter en gruppe er en del af den gruppe; underspørgsmål efter et spørgsmål er en del af det spørgsmål, og svar efter et spørgsmål er en del af det spørgsmål. Du behøver således ikke at kende ID'erne (gid, qid, sqid) for spørgsmål. Disse vil blive beregnet automatisk ved import. Faktisk bruger dette format slet ikke gid, qid eller sqid (eller SGQA-koder).

Tips

Målet med import/eksport med fane-separeret værdi er at lade dig hurtigt designe din undersøgelse ved hjælp af et regneark. Vi forventer, at du ofte vil importere arket, kontrollere dets gyldighed ved hjælp af funktionen "Vis undersøgelseslogik" og teste det. Hver gang du importerer det, får du en ny undersøgelse. Så du kan ende med mange delvist udviklede undersøgelser, men det er fint. Bare væn dig til at holde styr på, hvilken der er den seneste, eller slet den gamle, efter du har importeret de nye. Da du aldrig bruger SGQA-koder i Tab Separated Value, behøver du aldrig at bekymre dig om, hvilke koder LimeSurvey tildeler til den primære undersøgelses-, gruppe-, spørgsmåls- og svarnøgler. Så du er velkommen til at importere og eksportere, så ofte du vil.

Her er nogle praktiske ting, du kan gøre med denne tilgang til at oprette instrumenter:

1. Brug samme svar til mange spørgsmål. Bare kopier 'A'-rækkerne og indsæt efter hvert spørgsmål, der skal have det samme sæt.
2. Brug samme underspørgsmål til mange spørgsmål. Bare kopier 'SQ'-rækkerne og indsæt dem efter hvert spørgsmål, der har brug for det.
3. "Looping" - brug samme gruppe mange gange. Når gruppen er, som du vil have den, skal du kopiere den så mange gange som nødvendigt. Brug Excel-filtrering til kun at se 'G'-rækkerne (for grupper), og brug Excel-søjletrækfunktionen til at opdatere relevansligningerne for hver gruppe (f.eks. for en folketælling kan den første relevans være "antalPeople > 1", næste skal være "antalPeople > 2". Træk-funktionen vil automatisk opdatere tallet). Filtrer efter 'Q'-rækker og sørg for, at hvert spørgsmål har en unik værdi (f.eks. sig du navngiver dine variabler g1_q1, g1_q2, g1_qN, brug find/erstat til at konvertere g1 til g2 den anden gruppe; g3 for den tredje osv.) .
4. Ombestilling af spørgsmål/grupper. Du skal blot omarrangere rækkerne i regnearksfilen.
5. Test undersøgelsesmoduler. For lange undersøgelser kan det være en god idé at dele testen op i moduler. Du skal blot oprette nye regnearksfiler for hvert modul og slette alle rækker, du ikke har brug for. Dette undgår behovet for at indtaste masser af data for at teste senere sektioner af undersøgelsen.
6. Test obligatoriske spørgsmål. En almindelig klage er ikke behovet for at gøre mange spørgsmål obligatoriske, men behovet for at deaktivere den obligatoriske funktion til test. Du skal blot oprette hovedregnearket med obligatorisk indstillet til de endelige ønskede værdier. For derefter at teste det, skal du bare slette den "obligatoriske" kolonne og gemme testversionen af regnearket. Når du importerer den version, vil ingen af spørgsmålene være obligatoriske. Når du er færdig med din test, skal du importere masterkopien.
7. Indstilling af standarder. I stedet for at bruge GUI'en kan du indtaste alle ønskede standarder i standardkolonnen. Dette er især nyttigt i tilfælde, hvor GUI'en ikke lader dig indtaste den ønskede værdi, såsom udtryk for at indstille standarden for listeelementer (som at udfylde en liste fra en [[Survey-deltagere|undersøgelsesdeltager] ] attribut).
8. Oversættelse. Du kan oprette kopier af dit regneark - en pr. sprog. Inkluder alle rækkerne for det primære sprog, kopier og indsæt dem derefter nedenfor, og brug træk for at ændre sprogfeltet til målsproget. Disse kan distribueres til dine oversættere og genintegreres i en enkelt regnearksfil, når de er færdige.
9. Masseindstilling af avancerede spørgsmålsattributter. Du vil måske have, at alle dine ligninger begynder at være synlige (så du kan se deres værdier, mens du indsamler data), men derefter skjule dem alle, før du går i produktion. Du skal blot filtrere regnearket på klasse = 'Q' og spørgsmålstype = '*' (ligning), og indstille always_hide til 1 for hvert af disse spørgsmål. På samme måde, når du har oprettet undersøgelsen, bestemmer du, hvilke spørgsmål der skal vises i offentlige statistikker. I stedet for at redigere hvert spørgsmål gennem GUI'en, filtrer på klasse = 'Q' og sæt public_statistics = 1 for alle de spørgsmål, der skal være synlige i statistikker.
10. Find og erstat. Lad os sige, at du beslutter dig for at ændre nogle formuleringer på tværs af alle dine spørgsmål. Du kan bruge Excel Find og Erstat til at foretage disse ændringer. På samme måde kan du sige, at du beslutter dig for at lave en masseomdøbning af dine variabler, find og erstat kan komme til undsætning. Hvis du har brug for regulært udtryksbaseret find og erstat, kan du vælge den ønskede kolonne, kopiere til en teksteditor, finde og erstatte og indsætte kolonnen tilbage i regnearket.
11. 'Gain approvals '. Hvis du laver research, har du muligvis en institutionel revisionskomité, som insisterer på at se teksten til spørgsmålene. Dette kan være en praktisk måde at dele det på. Tilsvarende for diskussioner med en klient.
12. Teamkonsensus. Hvis du forsøger at få en gruppe til at blive enige om ordlyden eller udseendet af et spørgsmål eller en gruppe, kan du hurtigt prototype/redigere regnearket, importere det og vise teamet (via spørgsmål eller gruppeeksempel) præcis, hvad brugerne vil se . På den måde kan du få godkendelse fra teamet, før de forlader lokalet i stedet for at skulle dokumentere krav, bygge dem og få godkendelse ved fremtidige møder.
13. Opgradering fra andre undersøgelsesformater. Hvis din undersøgelse er i XML, Word eller andet format, kan du oprette en oversættelsesproces for at knytte dem til dette format. Selvom du også kunne prøve at kortlægge til .lss-formatet, er fordelen ved dette format, at det ikke kræver, at du holder styr på fremmednøgleforhold mellem grupper, spørgsmål, underspørgsmål, svar og standardindstillinger.

Begrænsninger

1. På design fungerer denne funktion kun korrekt for undersøgelser, der bruger qcode (i stedet for SGQA) navngivning. Denne funktion antager, at variabelnavne (spørgsmålsidentifikatorer) er unikke i hele undersøgelsen. Underspørgsmålsnavne kan gentages, så længe de er unikke inden for rammerne af et bestemt spørgsmål.

Filformat

Generelt

Vi bruger det samme sæt kolonneoverskrifter til flere formål. De første 14 kolonner tjener forskellige formål afhængigt af typen af enhed (f.eks. gruppe, spørgsmål, svar). De resterende kolonner er en alfabetisk liste over databasefeltnavnene for de avancerede spørgsmålskoder. Nedenfor er syntaksen for hver enhedstype

De første 14 kolonner er:

1. id ^{(New in 3.14.0 )}
2. related_id ^{(New in 3.14.0 )}
3. class
4. type/scale
5. navn
6. relevans
7. tekst
8. hjælp
9. sprog
10. validering
11. obligatorisk
12. other
13. default
14. same_default

 Hint: Kolonne-id og relateret_id bruges kun til kvote og er valgfri. Hvis du ikke har en kvote, kan du fjerne disse 2 kolonner direkte.

Globale parametre for undersøgelse

Der er én række pr. parameter i undersøgelsestabellen.

1. class => 'S'
2. name => databasefeltnavn
3. text => værdi

Sprogspecifikke parametre for undersøgelse

Der er én række pr. felt pr. sprog i tabellen surveys_languagesettings. Alle indtastninger for et givet sprog indsamles, før indsættelsen udføres i tabellen.

1. class => 'SL'
2. name => databasefeltnavn
3. text => værdi
4. language = > sprog

Grupper

One group row per survey language (e.g., there would be 3 group rows if survey has 3 languages).

1. id => unique numeric identifier for the group, starting with number 1, use the same ID for additional languages belonging to current group
2. class => 'G'
3. name => group_name -- the unique identifier for the group
4. relevance => grelevance -- the group-level relevance equation, without curly braces
5. text => description -- the language-specific description of the group
6. language => language -- the language for the group (e.g., 'en')

Questions

One question row per survey language (e.g., there would be 3 question rows if survey has 3 languages). Questions are assumed to belong to the group that precedes them.

1. id => unique numeric identifier for the question, starting with number 1, use the same ID for additional languages belonging to current question
2. class => 'Q'
3. type/scale => type -- the (usually one letter) question type (e.g., 'M' is Multiple Choice)
4. name => title -- the unique question name (the root of the qcode naming system)
5. relevance => relevance -- the relevance equation for the question
6. text => question -- the language-specific text of the question
7. help => help -- the language-specific help text
8. language => language -- the language for the group (e.g., 'en')
9. validation => preg -- the optional regular expression validation criteria for the question
10. mandatory => mandatory -- 'Y' if mandatory
11. other => other -- 'Y' if the "Other" option should be available (only for some question types)
12. default => default -- if set, this value is inserted into the defaultvalues table for this question
13. same_default => same_default -- 'Y' for true, in which case any defaultvalue set for primary language applies to other languages

Subquestions

One subquestion row per survey language. Subquestions are assumed to belong to the question that precedes them.

1. id => same unique numeric identifier which is used for the questions. Subquestions should use next available value, question and subquestion IDs should be different (e.g. use ID 1 for question and IDs 2, 3 and 4 for subquestions belonging to question 1, next question ID should be 5 and so on). Use the same subquestion ID for additional languages belonging to current subquestions.
2. class => 'SQ'
3. type/scale => scale_id -- 0 or 1, depending upon question type (e.g. array text will have two scales)
4. name => title -- the "name" of the subquestion, e.g. the one used for exclude_all_others
5. relevance => relevance -- (Future) to support subquestion-level relevance
6. text => question -- the language-specific text of the subquestion
7. help => help -- (Future) to support subquestion-level help
8. language => language -- the language for the subquestion
9. validation => preg -- (Future) to support subquestion-level regular expression validation (e.g. for address parts)
10. mandatory => mandatory -- (Future) to support subquestion-level mandatory (e.g. make only a few subquestions mandatory)
11. default => default -- if set, then this is the default value for the subquestion (inserted into defaultvalues table)
12. same_default => same_default -- if set, then the default for the primary language is  used for all other languages

Answers

One answer row per survey language (e.g., there would be 3 answer rows if survey has 3 languages). Answers are assumed to belong to the question that precedes them, and be in the desired sort order.

1. id => use the same ID as the ID of the question it belongs to
2. class => 'A'
3. type/scale => scale_id -- 0 or 1 (e.g. for dual-scale)
4. name => code -- the unique answer identifier
5. relevance => assessment_value -- if using assessment option, this is the assessment value for the answer
6. text => answer -- the language-specific text of the answer
7. language => language -- the language for this answer (e.g. 'en')

Assessments

One assessment row per survey language (e.g., there would be 3 assessment rows if survey has 3 languages). Assessments are written at the end of file.

1. id => unique numeric identifier for the assessment, starting with number 1, use the same ID for additional languages belonging to current assessment
2. related_id => id of group to which current assessment belongs to
3. class => 'AS'
4. type/scale => assessment scope: T-Total, G-group
5. name => name
6. text => message
7. min_num_value => Minimum
8. max_num_value => Maximum
9. language => language -- the language for this answer (e.g. 'en')

Quotas

One row per quota. Quotas are written at the end of file.

1. id => unique numeric identifier for the quota, starting with number 1
2. class => 'QTA'
3. name => quota name
4. mandatory => limit
5. other => quota action
6. default => active
7. same_default => autoload URL

Quota language settings

One quota row per survey language. Quota language settings are assumed to belong to the quota that precedes them.

1. id => unique numeric identifier for the quota language settings, starting with number 1. Each row for different survey languages should have different IDs
2. related_id => quota id of quota to which this setting belongs to
3. class => 'QTALS'
4. relevance => message
5. text => URL
6. help => URL description
7. language => language -- the language for this quota (e.g. 'en')

Quota members

One row per quota member, no language dependent. Quota member row should be placed immediately after question it relates to. Quota members are assumed to belong to the question that precedes them.

1. id => unique numeric identifier for the quota members, starting with number 1
2. related_id => quota id of quota to which this member belongs to
3. class => 'QTAM'
4. name => answer code

Conditions

One row per condition, no language dependent. Condition row should be placed immediately after question it relates to. Conditions are assumed to belong to the question that precedes them.

1. id => unique numeric identifier for the condition, starting with number 1.
2. related_id => question id of related question, if applicable
3. class => 'C'
4. type/scale => scenario
5. name => answer field name
6. relevance => comparison operator
7. text => expected answer