Actions

Translations

Tab Separated Value survey structure/15/en: Difference between revisions

From LimeSurvey Manual

(Importing a new version from external source)
(Importing a new version from external source)
 
Line 6: Line 6:
#'''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.
#'''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.
#'''Testing mandatory questions'''. A common complaint is not 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 to 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.
#'''Testing mandatory questions'''. A common complaint is not 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 to 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.
#'''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 [[Survey participants|survey participant]] attribute).
#'''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 [[ExpressionScript - Presentation|expressions]] to set the default for list items (like populating a list from a [[Survey participants|survey participant]] attribute).
#'''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.
#'''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.
#'''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.
#'''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.

Latest revision as of 16:30, 19 May 2020

Message definition (Tab Separated Value survey structure)
Here are some convenient things you can do with this approach to authoring instruments:
#'''Use same Answers for many questions'''. Just copy the 'A' rows and paste after each question that should have the same set.
#'''Use same subquestions for many questions'''. Just copy the 'SQ' rows and paste them after each question that needs it.
#'''"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.).
#'''Re-ordering questions/groups'''. Simply re-order the rows of the spreadsheet file.
#'''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.
#'''Testing mandatory questions'''. A common complaint is not 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 to 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.
#'''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 [[ExpressionScript - Presentation|expressions]] to set the default for list items (like populating a list from a [[Survey participants|survey participant]] attribute).
#'''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.
#'''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.
#'''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.
#'''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.
#'''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.
#'''Upgrading from other survey formats'''. If your survey is 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, subquestions, answers, and defaults.

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 subquestions 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 not 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 to 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 survey participant 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 your survey is 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, subquestions, answers, and defaults.