В заключение към Част 2 от тази поредица от статии споменах, че ще добавя по-разширени функции, като например:
- Условно подреждане на въпросите в анкета или с други думи възможността за условен път през анкетата
- Администрация на анкетата
- Отчети и анализ
В тази трета статия, свързана с онлайн проучване , ще разширя функционалността, за да поддържам условно подреждане на въпроси.
В бъдеще може да добавим въпроси, които изискват оценен отговор. Например:„Колко харесвате дизайна на базата данни, оценете между 1 и 100 (с 1 означава, че ви харесва много малко, а 100 показва, че ви харесва изключително много)?“
Условен път
Искаме да зададем определени условия за въпросите, представени на потребителя, въз основа на отговорите на потребителите. Например, ако отговорът на въпрос 4 е „да“, тогава задаваме въпрос 5 и пропускаме 6; докато ако отговорът на въпрос 4 е „не“, тогава пропускаме въпрос 5 и задаваме въпрос 6).
Така че трябва да дефинираме кои въпроси са условни и как да „пропускаме“ въпроси въз основа на отговора на въпрос.
Първоначално, за да поддържаме условния път прост, няма да допускаме условия, базирани на въпроси с множествен избор, а само за полярни (да или не) въпроси. Дизайнът може да бъде разширен, за да поддържа условни пътища, базирани на въпроси с множествен избор, но това е по-сложно и искам да започна просто.
Важно е приложението да проверява този поток за всеки въпрос, тъй като отговорът на предишен въпрос може да реши потока за текущия въпрос (за да пропуснете въпрос въз основа на предишен отговор).
Администриране и отчети
Засега няма да добавяме администратори на онлайн анкетите, но ще ги запазим за следващото разширение.
Ще трябва да има някои отчети и анализи; обаче ще запазя това за следващата версия, тъй като искам първо да съхраня някаква информация, за да извърша анализи по-късно.
Съекти и връзки
За условния път през анкетата ще разширя question_order който е дефиниран за всяко проучване и свързва анкетата с въпросите. Както споменахме, засега условният скок ще се основава само на полярни въпроси, така че мога да дефинирам следващия въпрос за показване в случай на положителен отговор и следващия въпрос, който да се показва в случай на отрицателен отговор.
Официален дизайн
Нека разширим ERD, създаден в Част 1 от тази поредица от статии.
Ще добавя conditional_order свързан към question_order; както споменах по-рано, ще подкрепя само условен ред чрез анкетата, базирана на полярни въпроси. Сега има няколко начина, по които това може да се приложи. Моите нужди са ясни, така че ще избера ясна реализация. Ако вашите нужди са по-сложни, ще ви трябва по-сложно решение.
Би било хубаво просто да дефинираме „следващия“ въпрос, който да бъде зададен въз основа на отговора на текущия въпрос, но това няма да ни позволи да пропуснем въпрос по-късно в анкетата, така че се нуждаем от повече гъвкавост.
Един от начините е да посочите колко въпроса да продължите напред в случай на положителен отговор и колко да продължите напред при отрицателен отговор; обаче трябва да уточня за кой въпрос се прилага прескокът и отговорът на кой въпрос да се използва. Така че в подкрепа на моя пример:ако отговорът на въпрос 4 е „да“, тогава задаваме въпрос 5 и пропускаме въпрос 6, докато ако отговорът на въпрос 4 е „не“, тогава пропускаме въпрос 5 и задаваме въпрос 6 -- това изисква две вписвания, като и двете проверяват отговора на въпрос 4, едното се движи напред с един въпрос (както обикновено) и едното прескача два въпроса напред (за пропускане на въпрос), а другото условие да бъде проверено след отговор на въпрос 5, което пропуска въпрос 6.
+-------------------+----------------------+------------------------+------------------------+ | question_order_id | response_to_question | positive_response_jump | negative_response_jump | +-------------------+----------------------+------------------------+------------------------+ | 4 | 4 | 1 | 2 | +-------------------+----------------------+------------------------+------------------------+ | 5 | 4 | 1 | null | +-------------------+----------------------+------------------------+------------------------+
Алтернатива е да посочите идентификатора на следващия въпрос, към който анкетата трябва да премине в случай на конкретен отговор:следващия въпрос в случай на положителен отговор и следващия въпрос в случай на отрицателен отговор. Този подход има плюсове и минуси. Това ще позволи да се появят цикли, които администраторът може да не забележи. Въпреки това, циклите може да са желан ефект, така че да можете да накарате последния въпрос да попитате респондента дали са приключили с анкетата и ако отговорят с „не“, след това се върнете към първия въпрос. Освен това въпросите, към които да преминете в случай на положителен или отрицателен отговор, могат да бъдат зададени като външни ключове към реда на въпросите, посочени за анкетата, така че да знаем със сигурност, че посоченият въпрос е дефиниран в анкетата. Това е добра логика за проверка, реализирана чрез референтна цялост. Мисля, че това вероятно е по-доброто решение, така че това ще намерите в ERD.
Така че в подкрепа на моя пример:ако отговорът на въпрос 4 е „да“, тогава задаваме въпрос 5 и пропускаме въпрос 6, докато ако отговорът на въпрос 4 е „не“, тогава пропускаме въпрос 5 и задаваме въпрос 6.
Както споменахме, имаме два реда:
Survey #1, question #4, response to question #4, positive response: next question order id = 5, negative response: next question order id = 6.
Survey #1, question #5, response to question #4, positive response: next question order id = 7. We will never get to question #5 if the response to question #4 was negative, so we always skip question #6 after asking question #5.
+--------+----------+----------------------+-------------------------------+-------------------------------+ | survey | question | response_to_question | positive_response_question_id | negative_response_question_id | +--------+----------+----------------------+-------------------------------+-------------------------------+ | 1 | 4 | 4 | 5 | 6 | +--------+----------+----------------------+-------------------------------+-------------------------------+ | | 5 | 4 | 7 | null | +--------+----------+----------------------+-------------------------------+-------------------------------+
Когато настройваме условието, ще използваме външен ключ (не е задължителен), за да гарантираме, че следващият въпрос съществува. Нулева стойност се използва за път, който не е възможен или, ако не е посочен следващ въпрос, за условно прекратяване на анкетата.
Оцветих таблиците, създадени в Част 1 от поредицата статии в жълто , таблиците, добавени в Част 2 в оранжево , а новодобавената таблица в зелено , така че по-лесно да виждате допълненията.
Заключение
Нито едно от описаните решения за управление на условни стъпки чрез анкета не е най-добрата система, базирана на правила, но една от целите ми е да поддържам нещата прости и ясни. Позволяване на гъвкавост, без да претоварвате нещата в сложност. И, ще се повторя, може да имате други изисквания. Идентифицирайте вашите изисквания; прилагайте или адаптирайте това, от което се нуждаете. Силно вярвам в повторната употреба, а не в преоткриването на колелото.
Сега започнахме да прилагаме подобренията, които бяха обсъдени в части 1 и 2 от тази поредица от статии.
В следващите статии ще добавя поддръжка за тези функции:
- Администриране на проучванията
- Отчети и анализи
