I konklusionen til Del 2 af denne serie af artikler nævnte jeg, at jeg ville tilføje mere avancerede funktioner, såsom:
- Betinget rækkefølge af spørgsmål i en undersøgelse eller med andre ord muligheden for en betinget vej gennem undersøgelsen
- Administration af undersøgelsen
- Rapporter og analyse
I denne tredje artikel relateret til en onlineundersøgelse , vil jeg udvide funktionaliteten til at understøtte betinget rækkefølge af spørgsmål.
I fremtiden kan vi tilføje spørgsmål, der kræver et bedømt svar. For eksempel:"Hvor meget kan du lide databasedesign, bedøm mellem 1 og 100 (hvor 1 indikerer, at du kan lide det meget lidt, og 100 indikerer, at du kan lide det utroligt)?"
Betinget sti
Vi ønsker at stille visse betingelser for de spørgsmål, der stilles til brugeren baseret på brugernes svar. For eksempel, hvis svaret på spørgsmål 4 er "ja", stiller vi spørgsmål 5 og springer spørgsmål 6 over. mens hvis svaret på spørgsmål 4 er "nej", så springer vi spørgsmål 5 over og stiller spørgsmål 6).
Så vi er nødt til at definere, hvilke spørgsmål der er betingede, og hvordan man "springer over" spørgsmål baseret på svaret på et spørgsmål.
I første omgang, for at holde den betingede vej enkel, vil vi ikke tillade betingelser baseret på multiple choice-spørgsmål, men kun for polære (ja eller nej) spørgsmål. Designet kan udvides til at understøtte betingede stier baseret på multiple choice-spørgsmål, men det er mere komplekst, og jeg vil starte enkelt.
Det er vigtigt, at applikationen kontrollerer dette flow for hvert spørgsmål, da svaret på et tidligere spørgsmål kan bestemme flowet for det aktuelle spørgsmål (for at springe et spørgsmål over baseret på et tidligere svar).
Administration og rapporter
Indtil videre tilføjer vi ikke administratorer af onlineundersøgelserne, men beholder det til næste udvidelse.
Der skal være nogle rapporter og analyser; Jeg vil dog beholde dette til næste version, da jeg vil gemme nogle oplysninger først for at udføre analyser senere.
Enheder og relationer
For den betingede sti gennem undersøgelsen vil jeg udvide question_order der er defineret for hver undersøgelse og forbinder undersøgelsen med spørgsmålene. Som nævnt, indtil videre, det betingede spring vil kun være baseret på polære spørgsmål, så jeg kan definere det næste spørgsmål, der skal vises i tilfælde af et positivt svar, og det næste spørgsmål, der skal vises i tilfælde af et negativt svar.
Formelt design
Lad os udvide den ERD, der blev oprettet i Del 1 af denne serie af artikler.
Jeg tilføjer conditional_order knyttet til question_order; som jeg nævnte tidligere, vil jeg kun støtte betinget orden gennem undersøgelsen baseret på polære spørgsmål. Nu er der et par måder, dette kan implementeres på. Mine behov er ligetil, så jeg vil vælge en ligetil implementering. Hvis dine behov er mere komplekse, har du brug for en mere kompleks løsning.
Det ville være rart blot at definere det "næste" spørgsmål, der skal stilles, baseret på svaret på det aktuelle spørgsmål, men det vil ikke tillade os at springe et spørgsmål over senere i undersøgelsen, så vi har brug for mere fleksibilitet.
En måde er at specificere, hvor mange spørgsmål der skal gå videre i tilfælde af et positivt svar, og hvor mange der skal gå videre på et negativt svar; jeg skal dog specificere hvilket spørgsmål springet gælder for og svaret på hvilket spørgsmål der skal bruges. Så for at støtte mit eksempel:Hvis svaret på spørgsmål 4 er "ja", så stiller vi spørgsmål 5 og springer spørgsmål 6 over, mens hvis svaret på spørgsmål 4 er "nej", så springer vi spørgsmål 5 over og stiller spørgsmål 6 -- dette kræver to poster, som begge kontrollerer svaret på spørgsmål 4, én flytter et spørgsmål frem (som sædvanligt) og én springer to spørgsmål frem (for at springe et spørgsmål over), og den anden betingelse skal kontrolleres efter besvarelse af spørgsmål 5, som springer spørgsmålet over 6.
+-------------------+----------------------+------------------------+------------------------+ | question_order_id | response_to_question | positive_response_jump | negative_response_jump | +-------------------+----------------------+------------------------+------------------------+ | 4 | 4 | 1 | 2 | +-------------------+----------------------+------------------------+------------------------+ | 5 | 4 | 1 | null | +-------------------+----------------------+------------------------+------------------------+
Et alternativ er at angive id'et for det næste spørgsmål, som undersøgelsen skal hoppe til i tilfælde af et bestemt svar:næste spørgsmål i tilfælde af positivt svar og næste spørgsmål i tilfælde af negativt respons. Denne tilgang har fordele og ulemper. Det ville tillade sløjfer at forekomme, som en administrator måske ikke bemærker. Men loops kan være en ønsket effekt, så du kan få det sidste spørgsmål til at spørge respondenten, om de er færdige med undersøgelsen, og hvis de svarer "nej", så vend tilbage til det første spørgsmål. Derudover kan de spørgsmål, der skal springes til i tilfælde af et positivt eller negativt svar, sættes op som fremmednøgler til den rækkefølge af spørgsmål, der er specificeret for undersøgelsen, så vi ved med sikkerhed, at det angivne spørgsmål er defineret i undersøgelsen. Dette er en god check-in-logik implementeret gennem referentiel integritet. Jeg tror, at dette nok er den bedre løsning, så det er det, du finder i ERD.
Så for at støtte mit eksempel:Hvis svaret på spørgsmål 4 er "ja", så stiller vi spørgsmål 5 og springer spørgsmål 6 over, mens hvis svaret på spørgsmål 4 er "nej", så springer vi spørgsmål 5 over og stiller spørgsmål 6.
Som nævnt har vi to rækker:
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 | +--------+----------+----------------------+-------------------------------+-------------------------------+
Når vi opsætter betingelsen, vil vi bruge en fremmednøgle (ikke obligatorisk) for at sikre, at det næste spørgsmål eksisterer. En nulværdi bruges til en sti, der ikke er mulig, eller, hvis der ikke er angivet noget næste spørgsmål, for at afslutte undersøgelsen betinget.
Jeg har farvelagt de tabeller, der blev oprettet i Del 1 af artikelserien i gul , tabellerne tilføjet i Del 2 i orange og den nyligt tilføjede tabel i grøn , så det er nemmere at se tilføjelserne.
Konklusion
Ingen af de løsninger, der er beskrevet til håndtering af betingede trin gennem en undersøgelse, er det ultimative regelbaserede system, men et af mine mål er at holde tingene enkle og ligetil. Tillader fleksibilitet uden at overvælde ting i kompleksitet. Og jeg gentager mig selv, du har muligvis andre krav. Identificer dine krav; implementere eller tilpasse det, du har brug for. Jeg tror stærkt på genbrug og ikke at genopfinde hjulet.
Nu er vi begyndt at implementere de forbedringer, som blev diskuteret i del 1 og 2 i denne artikelserie.
I de næste artikler vil jeg tilføje understøttelse af disse funktioner:
- Administration af undersøgelserne
- Rapporter og analyser