In de conclusie van Deel 2 van deze serie artikelen zei ik dat ik meer geavanceerde functies zou toevoegen, zoals:
- Voorwaardelijke volgorde van vragen in een enquête of, met andere woorden, de mogelijkheid voor een voorwaardelijk pad door de enquête
- Beheer van de enquête
- Rapporten en analyse
In dit derde artikel over een online enquête , Ik zal de functionaliteit uitbreiden om voorwaardelijke volgorde van vragen te ondersteunen.
In de toekomst kunnen we vragen toevoegen die een beoordeeld antwoord vereisen. Bijvoorbeeld:"Hoe leuk vind je databaseontwerp, een cijfer tussen 1 en 100 (waarbij 1 aangeeft dat je het heel weinig leuk vindt en 100 dat je het enorm leuk vindt)?"
Voorwaardelijk pad
We willen bepaalde voorwaarden stellen aan de vragen die aan de gebruiker worden voorgelegd op basis van gebruikersreacties. Als het antwoord op vraag 4 bijvoorbeeld 'ja' is, stellen we vraag 5 en slaan we vraag 6 over; terwijl als het antwoord op vraag 4 'nee' is, we vraag 5 overslaan en vraag 6 stellen.
We moeten dus definiëren welke vragen voorwaardelijk zijn en hoe we vragen kunnen 'overslaan' op basis van het antwoord op een vraag.
Om het voorwaardelijke pad eenvoudig te houden, zullen we in eerste instantie geen voorwaarden op basis van meerkeuzevragen toestaan, maar alleen voor polaire (ja of nee) vragen. Het ontwerp kan worden uitgebreid om voorwaardelijke paden te ondersteunen op basis van meerkeuzevragen, maar dat is complexer en ik wil simpel beginnen.
Het is belangrijk dat de applicatie deze stroom voor elke vraag controleert, omdat het antwoord op een vorige vraag de stroom voor de huidige vraag kan bepalen (om een vraag over te slaan op basis van een eerder antwoord).
Beheer en rapporten
Voorlopig zullen we geen beheerders van de online enquêtes toevoegen, maar dat bewaren voor de volgende extensie.
Er zullen enkele rapporten en analyses moeten zijn; ik bewaar dit echter voor de volgende versie, omdat ik eerst wat informatie wil opslaan om later analyses uit te voeren.
Entiteiten en relaties
Voor het voorwaardelijke pad door de enquête, zal ik de question_order . verlengen dat voor elke enquête wordt gedefinieerd en de enquête koppelt aan de vragen. Zoals gezegd, voorlopig de voorwaardelijke sprong zal alleen gebaseerd zijn op polaire vragen, dus ik kan de volgende vraag definiëren die moet worden weergegeven in het geval van een positief antwoord en de volgende vraag die moet worden weergegeven in het geval van een negatief antwoord.
Formeel ontwerp
Laten we de ERD uitbreiden die is gemaakt in Deel 1 van deze serie artikelen.
Ik zal conditional_order toevoegen gekoppeld aan question_order; zoals ik eerder al zei, zal ik alleen voorwaardelijke volgorde ondersteunen via de enquête op basis van polaire vragen. Nu zijn er een paar manieren waarop dit kan worden geïmplementeerd. Mijn behoeften zijn rechttoe rechtaan, dus ik zal voor een rechttoe rechtaan implementatie kiezen. Als uw behoeften complexer zijn, heeft u een complexere oplossing nodig.
Het zou leuk zijn om de "volgende" vraag die moet worden gesteld te definiëren op basis van het antwoord op de huidige vraag, maar daardoor kunnen we later in de enquête geen vraag overslaan, dus we hebben meer flexibiliteit nodig.
Eén manier is om te specificeren hoeveel vragen er verder moeten worden gesteld in het geval van een positief antwoord en hoeveel vragen er verder moeten worden gesteld bij een negatief antwoord; ik moet echter specificeren voor welke vraag de sprong van toepassing is en het antwoord van welke vraag moet worden gebruikt. Dus om mijn voorbeeld te ondersteunen:als het antwoord op vraag 4 "ja" is, stellen we vraag 5 en slaan vraag 6 over, terwijl als het antwoord op vraag 4 "nee" is, we vraag 5 overslaan en vraag 6 stellen -- hiervoor zijn twee items nodig die beide het antwoord op vraag 4 controleren, de ene gaat één vraag vooruit (zoals gewoonlijk) en de andere springt twee vragen vooruit (om een vraag over te slaan), en de andere voorwaarde die moet worden gecontroleerd na het beantwoorden van vraag 5 die vraag overslaat 6.
+-------------------+----------------------+------------------------+------------------------+ | question_order_id | response_to_question | positive_response_jump | negative_response_jump | +-------------------+----------------------+------------------------+------------------------+ | 4 | 4 | 1 | 2 | +-------------------+----------------------+------------------------+------------------------+ | 5 | 4 | 1 | null | +-------------------+----------------------+------------------------+------------------------+
Een alternatief is het specificeren van de id van de volgende vraag waarnaar de enquête moet springen in het geval van een bepaald antwoord:volgende vraag in geval van positief antwoord en volgende vraag in geval van negatief antwoord. Deze aanpak heeft voor- en nadelen. Hierdoor kunnen lussen ontstaan, die een beheerder misschien niet opmerkt. Loops kunnen echter een gewenst effect zijn, zodat u de laatste vraag aan de respondent kunt laten vragen of hij klaar is met de enquête en als hij 'nee' antwoordt, keer dan terug naar de eerste vraag. Bovendien kunnen de vragen waarnaar moet worden gesprongen in geval van een positief of negatief antwoord worden ingesteld als externe sleutels voor de volgorde van de vragen die voor de enquête zijn opgegeven, zodat we zeker weten dat de opgegeven vraag in de enquête is gedefinieerd. Dit is een mooie check-in-logica die is geïmplementeerd door middel van referentiële integriteit. Ik denk dat dit waarschijnlijk de betere oplossing is, dus dat is wat je in de ERD zult vinden.
Dus om mijn voorbeeld te ondersteunen:als het antwoord op vraag 4 'ja' is, stellen we vraag 5 en slaan vraag 6 over, terwijl als het antwoord op vraag 4 'nee' is, we vraag 5 overslaan en vraag 6 stellen.
Zoals gezegd hebben we twee rijen:
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 | +--------+----------+----------------------+-------------------------------+-------------------------------+
Bij het instellen van de voorwaarde gebruiken we een externe sleutel (niet verplicht) om ervoor te zorgen dat de volgende vraag bestaat. Een null-waarde wordt gebruikt voor een pad dat niet mogelijk is of, als er geen volgende vraag is opgegeven, om de enquête voorwaardelijk te beëindigen.
Ik heb de tabellen gekleurd die zijn gemaakt in Deel 1 van de artikelreeks in geel , de tabellen toegevoegd in Deel 2 in oranje en de nieuw toegevoegde tabel in groen zodat het gemakkelijker is om de toevoegingen te zien.
Conclusie
Geen van de oplossingen die worden beschreven voor het beheren van voorwaardelijke stappen door middel van een enquête is het ultieme op regels gebaseerde systeem, maar een van mijn doelen is om dingen eenvoudig en duidelijk te houden. Flexibiliteit toestaan zonder dingen in complexiteit te overweldigen. En, ik herhaal mezelf, misschien heb je andere vereisten. Identificeer uw vereisten; implementeren of aanpassen wat u nodig heeft. Ik geloof sterk in hergebruik en niet het wiel opnieuw uitvinden.
Nu zijn we begonnen met het implementeren van de verbeteringen die werden besproken in deel 1 en 2 van deze serie artikelen.
In de volgende artikelen zal ik ondersteuning voor deze functies toevoegen:
- Beheer van de enquêtes
- Rapporten en analyses