x

Основни глави

  1. LimeSurvey Cloud срещу LimeSurvey CE
  2. LimeSurvey Cloud - Кратко ръководство за стартиране
  3. LimeSurvey CE - Монтаж
  4. Как да проектираме добро проучване (Ръководство)
  5. Приготвяме се да започнем
  6. Конфигурация на LimeSurvey
  7. Въведение - Анкети
  8. Вижте настройките на проучването
  9. Вижте менюто за проучване
  10. Вижте структурата на проучването
  11. Въведение - Въпроси
  12. Въведение - Групи въпроси
  13. Въведение – Проучвания – Управление
  14. Опции на лентата с инструменти за проучване
  15. Многоезично проучване
  16. Кратко ръководство за стартиране - ExpressionScript
  17. Разширени функции
  18. Общи ЧЗВ
  19. Отстраняване на неизправности
  20. Заобиколни решения
  21. Разрешително
  22. Дневник на промените на версията
  23. Плъгини - Разширени
 Actions

Структура на анкетата с разделени стойности

From LimeSurvey Manual

Revision as of 10:02, 23 November 2023 by Maren.fritz (talk | contribs) (Created page with "=Ограничения= #По дизайн тази функция работи правилно само за проучвания, които използват qcode (вм...")


Импортиране и експортиране на стойности, разделени с раздели на структурата на проучването

Тази функция е предназначена да улесни използването на софтуер за електронни таблици като LibreOffice, Excel или Google Docs за създаване и редактиране на анкети. Той напълно елиминира зависимостта от SGQA кодовете.

Тази функция поддържа импортиране от ASCII или UTF-8 кодирани файлове със стойности, разделени с разделители (TSV), които имат разширение .txt.


Template:Забележка


Първи стъпки

Най-лесният начин е да вземете съществуваща анкета и да я експортирате във формат с разделени стойности. Използвайте нормалния бутон за анкета за експортиране и вместо да изберете формат .lss, изберете „Формат на разделени стойности (*.txt)“. Той ще бъде записан като файл със стойности, разделени с табулатори в правилния формат (уникод файл с разделители на табулатори), с всички правилни заглавия на колони.

Всеки софтуер за електронни таблици, който поддържа стойности, разделени с табулатори, е подходящ (напр. OpenOffice или LibreOffice). LimeSurvey игнорира всяко форматиране в електронната таблица, но не се колебайте да добавите някои, ако ви помага.

Обърнете внимание, че експортираният файл е във формат UTF-8 с маркировката за ред на байтовете (BOM) като първите три (скрити) знака. Ако щракнете два пъти върху .txt и се опитате да го отворите директно с Excel, той няма да се отвори правилно, защото Excel не осъзнава, че е във формат UTF-8. За да отворите тези файлове с Excel, първо отворете Excel, след това изберете File:Open, изберете .txt файла и кажете на Excel, че използва UTF-8 кодиране.

Ще има по един ред за всяка група, въпрос, подвъпрос и отговор. Има също редове за глобални променливи на проучването и за специфични за езика променливи на проучването. Основният език ще бъде посочен първи, последван от всички вторични езици. Така че, ако има няколко езика, цялото съдържание на основния език ще се покаже първо (напр. всички групи, въпроси, подвъпроси и отговори). Това ще бъде последвано от преведено копие за всеки вторичен език (с абсолютно същия брой и ред или редове за преведения набор).

Отношенията се предполагат по близост. И така, въпросите след група са част от тази група; подвъпросите след въпрос са част от този въпрос, а отговорите след въпрос са част от този въпрос. По този начин не е необходимо да знаете идентификаторите (gid, qid, sqid) за всякакви въпроси. Те ще бъдат изчислени автоматично при импортиране. Всъщност този формат изобщо не използва gid, qid или sqid (или SGQA кодове).


Съвети

Целта на импортирането/експортирането на стойности, разделени с раздели, е да ви позволи бързо да проектирате проучването си с помощта на електронна таблица. Очакваме, че често ще импортирате листа, ще проверявате валидността му с помощта на функцията „Показване на логиката на проучването“ и ще го тествате. Всеки път, когато го импортирате, ще получите нова анкета. Така че може да се окажете с много частично разработени проучвания, но това е добре. Просто придобийте навика да следите коя е най-новата или изтрийте старата, след като импортирате новите. Тъй като никога не използвате SGQA кодове в стойността, разделена с раздели, никога не е необходимо да се притеснявате какви кодове задава LimeSurvey за основните ключове за проучване, група, въпрос и отговор. Така че, не се колебайте да импортирате и експортирате толкова често, колкото искате.

Ето някои удобни неща, които можете да правите с този подход за създаване на инструменти:

  1. Използвайте едни и същи отговори за много въпроси. Просто копирайте редовете 'A' и поставете след всеки въпрос, който трябва да има същия набор.
  2. Използвайте едни и същи подвъпроси за много въпроси. Просто копирайте редовете 'SQ' и ги поставете след всеки въпрос, който се нуждае от него.
  3. "Зацикляне" - използвайте една и съща група много пъти'. След като групата е такава, каквато искате, копирайте я толкова пъти, колкото е необходимо. Използвайте филтриране на Excel, за да видите само редовете „G“ (за групи), и използвайте функцията за плъзгане на колони на Excel, за да актуализирате уравненията за уместност за всяка група (напр. за преброяване на населението първата уместност може да бъде „numPeople > 1“, следващото трябва да е "numPeople > 2". Функцията за плъзгане ще актуализира автоматично номера). Филтрирайте по редове „Q“ и се уверете, че всеки въпрос има уникална стойност (напр. кажете, че назовавате променливите си g1_q1, g1_q2, g1_qN, използвайте find/replace, за да конвертирате g1 в g2 втората група; g3 за третата и т.н.) .
  4. 'Пренареждане на въпроси/групи. Просто пренаредете редовете на файла с електронната таблица.
  5. Тестване на модули за проучване. За дълги проучвания може да искате да разделите тестването на модули. Просто създайте нови файлове с електронни таблици за всеки модул, като изтриете всички редове, които не ви трябват. Това избягва необходимостта от въвеждане на много данни за тестване на по-късни секции от анкетата.
  6. Тестване на задължителни въпроси. Често срещано оплакване не е необходимостта много въпроси да бъдат задължителни, а необходимостта да се изключи задължителната функция за тестване. Просто създайте основната електронна таблица със задължителни настройки на крайните желани стойности. След това, за да го тествате, просто изтрийте колоната „задължително“ и запазете тестовата версия на електронната таблица. Когато импортирате тази версия, нито един от въпросите няма да е задължителен. След като приключите с тестването, импортирайте главното копие.
  7. Настройка по подразбиране. Вместо да използвате GUI, можете да въведете желаните настройки по подразбиране в колоната по подразбиране. Това е особено полезно в случаите, когато GUI не ви позволява да въведете желаната стойност, като изрази, за да зададете стойността по подразбиране за елементи от списък (като попълване на списък от [[Участници в проучване|участник в проучване] ] атрибут).
  8. 'Превод'. Можете да създадете копия на вашата електронна таблица - по едно на език. Включете всички редове за основния език, след това ги копирайте и поставете по-долу и използвайте плъзгане, за да промените езиковото поле на целевия език. Те могат да бъдат раздадени на вашите преводачи и повторно интегрирани в един файл с електронна таблица, когато са готови.
  9. 'Групова настройка на разширени атрибути на въпроси'. Може да искате всичките ви уравнения да започнат видими (за да можете да виждате стойностите им, докато събирате данни), но след това ги скрийте всички, преди да преминете към производство. Просто филтрирайте електронната таблица по клас = 'Q' и тип въпрос = '*' (уравнение) и задайте always_hide на 1 за всеки от тези въпроси. По същия начин, да речем, след като създадете анкетата, вие решавате кои въпроси да се показват в публичната статистика. Вместо да редактирате всеки въпрос чрез GUI, филтрирайте по class = 'Q' и задайте public_statistics = 1 за всички въпроси, които трябва да се виждат в статистиката.
  10. 'Намиране и заместване'. Да речем, че решите, че трябва да промените някои фрази във всичките си въпроси, можете да използвате Excel за намиране и замяна, за да направите тези промени. По същия начин, кажете, че сте решили да направите групово преименуване на вашите променливи, намирането и замяната може да дойде на помощ. Ако имате нужда от намиране и замяна, базирано на регулярен израз, можете да изберете желаната колона, да копирате в текстов редактор, да направите своето намиране и замяна и да поставите колоната обратно в електронната таблица.
  11. ''Получаване на одобрения '. Ако правите проучване, може да имате институционален съвет за преглед, който настоява да видите текста на въпросите. Това може да е удобен начин да го споделите. По същия начин за дискусии с клиент.
  12. Екипен консенсус. Ако се опитвате да накарате група да се съгласи с формулировката или външния вид на въпрос или група, можете бързо да прототипирате/редактирате електронната таблица, да я импортирате и да покажете на екипа (чрез преглед на въпрос или група) точно какво ще видят потребителите . По този начин можете да получите одобрение от екипа, преди да напуснат стаята, вместо да се налага да документирате изисквания, да ги изграждате и да получавате одобрение на бъдещи срещи.
  13. 'Надграждане от други формати на проучване'. Ако вашата анкета е в XML, Word или друг формат, можете да създадете процес на превод, за да ги съпоставите с този формат. Въпреки че можете също да опитате да картографирате във формат .lss, предимството на този формат е, че не изисква да следите връзките на външен ключ между групи, въпроси, подвъпроси, отговори и настройки по подразбиране.


Ограничения

  1. По дизайн тази функция работи правилно само за проучвания, които използват qcode (вместо SGQA) наименуване. Тази функция предполага, че имената на променливите (идентификатори на въпроси) са уникални в цялата анкета. Имената на подвъпросите могат да се повтарят, стига да са уникални в обхвата на конкретен въпрос.


File Format

General

We use the same set of column headings for multiple purposes. The first 14 columns serve different purposes depending upon the type of entity (e.g., group, question, answer). The remaining columns are an alphabetical list of the database field names for the advanced question codes. Below is the syntax for each entity type

The first 14 columns are:

  1. id (New in 3.14.0 )
  2. related_id (New in 3.14.0 )
  3. class
  4. type/scale
  5. name
  6. relevance
  7. text
  8. help
  9. language
  10. validation
  11. mandatory
  12. other
  13. default
  14. same_default
 Hint: Columns id and related_id are used only for quota and are optional. If you don't have quota, you can directly remove this 2 columns.


Survey Global Parameters

There is one row per parameter in the surveys table.

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


Survey Language-Specific 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

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