Na zakończenie Części 2 z tej serii artykułów wspomniałem, że dodałbym bardziej zaawansowane funkcje, takie jak:
- Warunkowe porządkowanie pytań w ankiecie lub innymi słowy możliwość warunkowej ścieżki przez ankietę
- Administracja ankiety
- Raporty i analityka
W tym trzecim artykule dotyczącym ankiety internetowej , rozszerzę funkcjonalność o obsługę warunkowego porządkowania pytań.
W przyszłości możemy dodać pytania wymagające oceny odpowiedzi. Na przykład:„Jak bardzo podoba Ci się projekt bazy danych, oceń od 1 do 100 (przy czym 1 oznacza, że bardzo Ci się podoba, a 100 oznacza, że bardzo Ci się podoba)?”
Ścieżka warunkowa
Chcemy ustalić pewne warunki dotyczące pytań przedstawianych użytkownikowi na podstawie odpowiedzi użytkownika. Na przykład, jeśli odpowiedź na pytanie 4 brzmi „tak”, to zadajemy pytanie 5 i pomijamy pytanie 6; natomiast jeśli odpowiedź na pytanie 4 brzmi „nie”, pomijamy pytanie 5 i zadajemy pytanie 6).
Dlatego musimy zdefiniować, które pytania są warunkowe i jak „pominąć” pytania na podstawie odpowiedzi na pytanie.
Początkowo, aby ścieżka warunkowa była prosta, nie dopuszczamy warunków opartych na pytaniach wielokrotnego wyboru, a jedynie na pytania biegunowe (tak lub nie). Projekt można rozszerzyć, aby obsługiwał ścieżki warunkowe oparte na pytaniach wielokrotnego wyboru, ale jest to bardziej złożone i chcę zacząć prosto.
Ważne jest, aby aplikacja sprawdzała ten przepływ dla każdego pytania, ponieważ odpowiedź na poprzednie pytanie może decydować o przepływie dla bieżącego pytania (aby pominąć pytanie na podstawie poprzedniej odpowiedzi).
Administracja i raporty
Na razie nie dodamy administratorów ankiet online, ale zachowamy to na następne rozszerzenie.
Potrzebne będą raporty i analizy; jednak zachowam to dla następnej wersji, ponieważ chcę najpierw przechowywać pewne informacje, aby później przeprowadzić analizę.
Podmioty i relacje
W przypadku warunkowej ścieżki przez ankietę rozszerzę question_order który jest zdefiniowany dla każdej ankiety i łączy ankietę z pytaniami. Jak wspomniano, na razie skok warunkowy będzie opierać się tylko na pytaniach biegunowych, więc mogę zdefiniować następne pytanie do wyświetlenia w przypadku pozytywnej odpowiedzi i następne pytanie do wyświetlenia w przypadku negatywnej odpowiedzi.
Projekt formalny
Rozszerzmy ERD, który został utworzony w Części 1 tej serii artykułów.
Dodam conditional_order połączone z question_order; jak wspomniałem wcześniej, będę wspierać tylko porządek warunkowy poprzez ankietę opartą na pytaniach polarnych. Teraz jest kilka sposobów na zaimplementowanie tego. Moje potrzeby są proste, więc wybiorę prostą implementację. Jeśli Twoje potrzeby są bardziej złożone, potrzebujesz bardziej złożonego rozwiązania.
Byłoby miło po prostu zdefiniować „następne” pytanie, które zostanie zadane na podstawie odpowiedzi na bieżące pytanie, ale to nie pozwoli nam pominąć pytania w dalszej części ankiety, więc potrzebujemy większej elastyczności.
Jednym ze sposobów jest określenie, ile pytań należy przejść do przodu w przypadku pozytywnej odpowiedzi i ile należy przejść do przodu w przypadku negatywnej odpowiedzi; muszę jednak sprecyzować, dla którego pytania ma zastosowanie przeskok i odpowiedzi na które pytanie. Aby poprzeć mój przykład:jeśli odpowiedź na pytanie 4 brzmi „tak”, to zadajemy pytanie 5 i pomijamy pytanie 6, natomiast jeśli odpowiedź na pytanie 4 brzmi „nie”, to pomijamy pytanie 5 i zadajemy pytanie 6 -- wymaga to dwóch wpisów, z których oba sprawdzają odpowiedź na pytanie, jednego przesuwającego się do przodu o jedno pytanie (jak zwykle) i jednego pomijającego dwa pytania do przodu (aby pominąć pytanie), oraz drugiego warunku do sprawdzenia po odpowiedzi na pytanie 5, które pomija pytanie 6.
+-------------------+----------------------+------------------------+------------------------+ | question_order_id | response_to_question | positive_response_jump | negative_response_jump | +-------------------+----------------------+------------------------+------------------------+ | 4 | 4 | 1 | 2 | +-------------------+----------------------+------------------------+------------------------+ | 5 | 4 | 1 | null | +-------------------+----------------------+------------------------+------------------------+
Alternatywą jest określenie id kolejnego pytania, na które ma przeskoczyć ankieta w przypadku konkretnej odpowiedzi:następne pytanie w przypadku pozytywnej odpowiedzi i następne pytanie w przypadku negatywnej odpowiedź. Takie podejście ma zalety i wady. Pozwoliłoby to na występowanie pętli, których administrator może nie zauważyć. Jednak pętle mogą być pożądanym efektem, dzięki czemu ostatnie pytanie może zapytać respondenta, czy zakończył ankietę, a jeśli odpowie „nie”, a następnie wrócić do pierwszego pytania. Dodatkowo pytania, do których można przejść w przypadku pozytywnej lub negatywnej odpowiedzi, mogą być ustawione jako klucze obce do kolejności pytań określonej w ankiecie, abyśmy wiedzieli na pewno, że dane pytanie jest zdefiniowane w ankiecie. Jest to ładne sprawdzenie logiki zaimplementowane przez integralność referencyjną. Myślę, że to chyba lepsze rozwiązanie, więc takie właśnie znajdziesz w ERD.
Aby poprzeć mój przykład:jeśli odpowiedź na pytanie 4 brzmi „tak”, to zadajemy pytanie 5 i pomijamy pytanie 6, natomiast jeśli odpowiedź na pytanie 4 brzmi „nie”, to pomijamy pytanie 5 i zadajemy pytanie 6.
Jak wspomniano, mamy dwa wiersze:
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 | +--------+----------+----------------------+-------------------------------+-------------------------------+
Podczas konfigurowania warunku użyjemy klucza obcego (nieobowiązkowego), aby upewnić się, że istnieje następne pytanie. Wartość null jest używana dla ścieżki, która nie jest możliwa lub, jeśli nie określono następnego pytania, do warunkowego zakończenia ankiety.
Pokolorowałem tabele utworzone w części 1 serii artykułów w kolorze żółtym, tabele dodane w Części 2 w kolorze pomarańczowym, a nowo dodana tabela w kolorze zielonym, aby łatwiej było zobaczyć dodatki.
Wniosek
Żadne z opisanych rozwiązań dotyczących zarządzania etapami warunkowymi za pomocą ankiety nie jest ostatecznym systemem opartym na regułach, ale jednym z moich celów jest zachowanie prostoty i przejrzystości. Umożliwienie elastyczności bez przytłaczania złożonością. I, powtarzam, możesz mieć inne wymagania. Określ swoje wymagania; zaimplementuj lub dostosuj to, czego potrzebujesz. Mocno wierzę w ponowne wykorzystanie, a nie wymyślanie koła na nowo.
Teraz rozpoczęliśmy wdrażanie ulepszeń, które zostały omówione w częściach 1 i 2 tej serii artykułów.
W następnych artykułach dodam obsługę tych funkcji:
- Administracja ankiet
- Raporty i analizy
