Tab Separated Value survey structure/nl

Deze functie is vanaf versie 2.0 beschikbaar.

Opmerking, deze functie is ook beschikbaar in 1.92, maar is toegevoegd na de 'feature freeze', het is dus geen onderdeel van de basiscode. Ervaren gebruikers kunnen deze functie toevoegen via GitHub

Excel (tabgescheiden) importeren en exporteren van enquête-structuur

Deze functie is ontworpen om het gebruik van een spreadsheetprogramma, zoals Excel, LibreOffice of Google-Docs, te vereenvoudigen. Het voorkomt dat je afhankelijk bent van SGQA-codes.

Deze functie is oorspronkelijk geschreven voor de ondersteuning van directe invoer uit Excel-geformatteerde bestanden (xls), de hiervoor gebruikte externe plugin is slecht onderhouden en de ondersteuning van UTF-8-codering (bijv. multi-lingual) is matig. Daarom ondersteunt de functie nu de invoer van ASCII of UTF-8 gecodeerd met door tabs gescheiden waarden (TSV) bestanden, een uitbreiding van txt-bestanden.

Beginnen

De eenvoudigste manier is om een bestaande enquête te pakken en die te exporteren in een 'Tab Separated Value'-formaat. Gebruik de normale exporteerknop, maar selecteer dan geen .lss formaat maar "LimeSurvey Tab Separated Value survey file (*.txt)".  Het uitvoerbestand is dan in het goede formaat (tab delimited unicode file), met de goede kolomkoppen.

Elk spreadsheetprogramma dat tab-separated-values ondersteunt, voldoet.  LimeSurvey kijkt niet naar de opmaak in de spreadsheet, maar je mag het wel gebruiken.

Het uitvoerbestand is in UTF-8 formaat met de Byte Order Mark (BOM) als de eerste drie (verborgen) tekens.  Als je dubbelklikt op dit bestand (.txt) en het direct in Excel probeert te openen, dan gaat het niet goed omdat Excel niet herkent dat het in UTF-8 is. Als je dit bestand in Excel wilt openen, start dan eerst Excel en lees dan het bestand via Excel en geef aan dat er UTF-8 encoding gebruikt is.

Er is een regel voor elke groep, vraag, subvraag en antwoord.  Er zijn ook regels voor globale enquêtevariabelen en voor taalspecifieke variabelen.  De standaardtaal wordt eerst getoond, gevolgd door de andere talen.  Als er meerdere talen zijn wordt eerst de gehele inhoud voor de standaardtaal in het bestand opgenomen.  Daarna voor elke andere gebruikte taal, met natuurlijk dezelfde indeling.

Regels zijn afhankelijk van de context.  Vragen die na een groep komen, zijn een onderdeel van die groep, subvragen na een vraag zijn subvragen van die vraag, antwoorden na een vraag zijn antwoorden op die vraag.  Er worden daarom geen ID's (gid, qid, sqid) bij vragen gebruikt.  Die worden automatisch toegekend bij het importeren.  In dit formaat worden dus geen gid, qid, of sqid (of SGQA codes) gebruikt.

Tips

Het doel van de "Tab Separated Value" import/export is dat je snel je enquête in een spreadsheet kunt ontwerpen.  Je kunt dit importeren meerdere keren na elkaar doen om je enquête in een aantal stappen steeds beter te maken, door de geldigheid met de functie "Show Survey Logic"  te testen, of door de enquête te testen. Na elke keer importeren heb je een nieuwe enquête, dus je kunt er een heel stel aanmaken. Zorg ervoor dat je oudere versies verwijderd als je ze niet meer nodig hebt bij het ontwerpen van je enquête.  Omdat je geen SGQA-codes gebruikt in het 'Tab Separated Value'-formaat, hoef je je ook geen zorgen te maken over de codes die LimeSurvey toekent aan de enquête, groep, vraag en antwoorden.

Here are some convenient things you can do with this approach to authoring instruments:

1. Use same Answers for many questions.  Just copy the 'A' rows and paste after each question that should have the same set.
2. Use same sub-questions for many questions.  Just copy the 'SQ' rows and paste them after each question that needs it.
3. "Looping" - use same group many times.  After the group is the way you want it, copy it as many times as needed.  Use Excel filtering to view just the 'G' rows (for groups), and use the Excel column drag feature to update the relevance equations for each group (e.g. for a census, the first relevance might be "numPeople > 1", the next should be "numPeople > 2".  The drag feature will auto-update the number).  Filter by 'Q' rows and ensure that each question has a unique value (e.g. say you name your variables g1_q1, g1_q2, g1_qN, use find/replace to convert g1 to g2 the second group; g3 for the third, etc.).
4. Re-ordering questions/groups.  Simply re-order the rows of the spreadsheet file.
5. Testing survey modules.  For long surveys, you may want to break up the testing into modules.  Simply create new spreadsheet files for each module, deleting any rows that you don't need. This avoids the need to enter lots of data to test later sections of the survey.
6. Testing mandatory questions.  A common complaint is the need to make many questions mandatory, but the need to turn off the mandatory feature for testing.  Simply create the master spreadsheet with mandatory set the the final desired values.  Then, to test it, just delete the "mandatory" column and save the test version of the spreadsheet.  When you import that version, none of the questions will be mandatory.  After you have finished your testing, import the master copy.
7. Setting defaults.  Rather than using the GUI, you can enter any desired defaults in the default column.  This is especially helpful for cases where the GUI does not let you enter the desired value, like Expressions to set the default for list items (like populating a list from a token attribute).
8. Translation.  You can create copies of your spreadsheet - one per language.  Include all the rows for the primary language, then copy and paste them below, and use drag to change the language field to the target language.  These can be distributed to your translators, and re-integrated into a single spreadsheet file when they are done.
9. Bulk setting of advanced question attributes.  You may want all of your equations to start visible (so you can see their values as you collect data), but then hide them all before going to production.  Simply filter the spreadsheet on class = 'Q' and question type = '*' (equation), and set always_hide to 1 for each of those questions.  Similarly, say after you create the survey, you decide which questions should appear in public statistics.  Rather than edit each question through the GUI, filter on class = 'Q', and set public_statistics = 1 for all of the questions that should be visible in statistics.
10. Find and replace.  Say you decide you need to change some phrasing across all of your questions, you can use Excel find and replace to make those changes.  Similarly, say you decide to do a bulk-renaming of your variables, find and replace can come to the rescue.  If you need regular-expression based find and replace, you can select the desired column, copy to a text editor, do your find and replace, and paste the column back into the spreadsheet.
11. Gaining approvals.  If you are doing research, you may have an Institutional Review board who insists upon seeing the text of the questions.  This may be a convenient way to share it.  Similarly for discussions with a client.
12. Team consensus.  If you are trying to get a group to agree upon the wording or appearance of a question or group, you can rapidly prototype / edit the spreadsheet, import it, and show the team (via question or group preview) exactly what the users will see.  That way you can get approval from the team before they leave the room rather than having to document requirements, build them, and get approval at future meetings.
13. Upgrading from other  survey formats.  If you have existing survey in XML, Word, or other format, you can create a translation process to map them to this format.  Although you could also try mapping to the .lss format, the advantage of this format is that it doesn't require you to keep track of foreign key relationships between groups, questions, sub-questions, answers, and defaults.

Limitations

1. By design, this feature only works properly for surveys that use qcode (rather than SGQA) naming.  This feature assumes that variable names (question identifiers) are unique throughout the survey. Sub-question names can be repeated, as long as they are unique within the scope of a particular question.
2. Currently, it does not import or export Conditions (since it assumes you'll be using relevance equations instead), Assessments (since it assumes you'll be using tailoring), or Quotas.  However, if there is enough demand, it would not be hard to add these.
3. Currently, the Tab Separated Value export feature does not export defaults for list-type questions.

File  Format

Algemeen

We gebruiken dezelfde groep kolomkoppen voor meerdere zaken.  De eerste 12 kolommen zijn voor verschillende doelen afhankelijk van het type van de regel (bijv. groep, vraag).  De andere kolommen is een alfabetische lijst van de databaseveldnamen voor de geadvanceerde vraagcodes.  De syntax per type staat hieronder

De eerste 12 kolommen:

1. class
2. type/scale
3. name
4. relevance
5. text
6. help
7. language
8. validation
9. mandatory
10. other
11. default
12. same_default

Enquête globale parameters

Er is een regel per parameter in de enquête-tabel.

1. class = 'S'
2. name => database field name
3. text => value

Enquete taalspecifieke parameters

There is one row per field per language in the surveys_languagesettings table.  All entries for a given language are collected before doing the insert into that table.

1. class = 'SL'
2. name => database field name
3. text => value
4. language => language

Groups

There is one row per group.

1. class = 'G'
2. name => group_name -- the unique identifier for the group
3. relevance => grelevance -- the group-level relevance equation, without curly braces
4. text => description -- the language-specific description of the group
5. language => language -- the language for the group (e.g. 'en')

Vragen

One row per question.  Questions are assumed to belong to the group that precedes them.

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

Subvragen

One row per sub-question.  Sub-questions are assumed to belong to the question that precedes them.

1. class = 'SQ'
2. type/scale => scale_id -- 0 or 1, depending upon question type (e.g. array text will have two scales)
3. name => title -- the "name" of the sub-question, e.g. the one used for exclude_all_others
4. relevance => relevance -- (Future) to support sub-question-level relevance
5. text => question -- the language-specific text of the sub-question
6. help => help -- (Future) to support sub-question-level help
7. language => language -- the language for the sub-question
8. validation => preg -- (Future) to support sub-question-level regular expression validation (e.g. for address parts)
9. mandatory => mandatory -- (Future) to support sub-question-level mandatory (e.g. make only a few sub-questions mandatory)
10. default => default -- if set, then this is the default value for the sub-question (inserted into defaultvalues table)
11. same_default => same_default -- if set, then the default for the primary language is  used for all other languages

Answoorden

One row per answer.  Answers are assumed to belong to the question that precedes them, and be in the desired sort order.

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

Voorbeelden

Relevantie, maatwerk en vergelijkingen

Discussie en schermafbeeldingen

ls2_em_tailoring.xls

Voorbeeld telling

Discussie en schermafbeeldingen

ls2_group_relevance.xls

Cascading Array Filters

Discussie en schermafbeeldingen

ls2_cascading_array_filter.xls

Traditional Validation, Re-envisioned

Discussion and Screen Shots

ls2_validation_tests.xls

Randomization Groups

Discussion and Screen Shots

Randomization_Group_Test.xls