Na conclusão da Parte 2 desta série de artigos, mencionei que estaria adicionando recursos mais avançados, como:
- Ordenação condicional das perguntas em uma pesquisa ou, em outras palavras, a possibilidade de um caminho condicional pela pesquisa
- Administração da pesquisa
- Relatórios e análise
Neste terceiro artigo relacionado a uma pesquisa online , estenderei a funcionalidade para oferecer suporte à ordenação condicional de perguntas.
No futuro, podemos adicionar perguntas que exigem uma resposta classificada. Por exemplo:“O quanto você gosta do design do banco de dados, avalie entre 1 e 100 (com 1 indicando que você gosta muito pouco e 100 indicando que você gosta imensamente)?”
Caminho condicional
Queremos definir certas condições nas perguntas apresentadas ao usuário com base nas respostas do usuário. Por exemplo, se a resposta para a pergunta 4 for "sim", fazemos a pergunta 5 e pulamos a pergunta 6; enquanto se a resposta para a pergunta 4 for "não", pularemos a pergunta 5 e faremos a pergunta 6).
Portanto, precisamos definir quais perguntas são condicionais e como “pular” perguntas com base na resposta a uma pergunta.
Inicialmente, para manter o caminho condicional simples, não permitiremos condições baseadas em questões de múltipla escolha, mas apenas para questões polares (sim ou não). O design pode ser estendido para oferecer suporte a caminhos condicionais com base em perguntas de múltipla escolha, mas isso é mais complexo e quero começar simples.
É importante que o aplicativo verifique esse fluxo para cada pergunta, pois a resposta a uma pergunta anterior pode decidir o fluxo da pergunta atual (pular uma pergunta com base em uma resposta anterior).
Administração e relatórios
Por enquanto, não adicionaremos administradores das pesquisas online, mas manteremos isso para a próxima extensão.
Será necessário haver alguns relatórios e análises; no entanto, manterei isso para a próxima versão, pois quero armazenar algumas informações primeiro para realizar análises posteriormente.
Entidades e Relacionamentos
Para o caminho condicional pela pesquisa, estenderei o
question_order que é definido para cada pesquisa e vincula a pesquisa às perguntas. Como mencionado, por enquanto, o salto condicional será baseado apenas em perguntas polares, para que eu possa definir a próxima pergunta a ser exibida em caso de resposta positiva e a próxima pergunta a ser exibida em caso de resposta negativa. Design formal
Vamos estender o ERD que foi criado na Parte 1 desta série de artigos.
Adicionarei
conditional_order vinculado a question_order; como mencionei anteriormente, só apoiarei a ordem condicional por meio da pesquisa com base em perguntas polares. Agora, existem algumas maneiras que isso pode ser implementado. Minhas necessidades são diretas, então escolherei uma implementação direta. Se suas necessidades forem mais complexas, você precisaria de uma solução mais complexa. Seria bom apenas definir a “próxima” pergunta a ser feita com base na resposta da pergunta atual, mas isso não nos permitirá pular uma pergunta mais tarde na pesquisa, então precisamos de mais flexibilidade.
Uma maneira é especificar quantas questões avançar em caso de resposta positiva e quantas avançar em caso de resposta negativa; no entanto, devo especificar para qual pergunta o salto se aplica e a resposta de qual pergunta deve ser usada. Então, para apoiar meu exemplo:se a resposta para a pergunta 4 for "sim", então fazemos a pergunta 5 e pulamos a pergunta 6, enquanto se a resposta para a pergunta 4 for "não", então pulamos a pergunta 5 e fazemos a pergunta 6 -- isso requer duas entradas que verificam a resposta à pergunta 4, uma avançando uma pergunta (como de costume) e outra pulando duas perguntas (para pular uma pergunta), e a outra condição a ser verificada após responder à pergunta 5 que pula a pergunta 6.
+-------------------+----------------------+------------------------+------------------------+ | question_order_id | response_to_question | positive_response_jump | negative_response_jump | +-------------------+----------------------+------------------------+------------------------+ | 4 | 4 | 1 | 2 | +-------------------+----------------------+------------------------+------------------------+ | 5 | 4 | 1 | null | +-------------------+----------------------+------------------------+------------------------+
Uma alternativa é especificar o id da próxima pergunta para a qual a pesquisa deve pular no caso de uma resposta específica:próxima pergunta em caso de resposta positiva e próxima pergunta em caso de resposta negativa resposta. Essa abordagem tem prós e contras. Isso permitiria a ocorrência de loops, que um administrador pode não perceber. No entanto, os loops podem ser um efeito desejado para que você possa fazer com que a pergunta final pergunte ao entrevistado se ele terminou a pesquisa e, se ele responder “não”, retorne à primeira pergunta. Além disso, as perguntas para as quais pular no caso de uma resposta positiva ou negativa podem ser configuradas como chaves estrangeiras para a ordem das perguntas especificadas para a pesquisa, para que tenhamos certeza de que a pergunta especificada está definida na pesquisa. Esta é uma boa lógica de verificação implementada por meio da integridade referencial. Eu acho que esta é provavelmente a melhor solução, então é isso que você encontrará no ERD.
Então, para apoiar meu exemplo:se a resposta da pergunta 4 for "sim", fazemos a pergunta 5 e pulamos a pergunta 6, enquanto se a resposta da pergunta 4 for "não", pulamos a pergunta 5 e fazemos a pergunta 6.
Como mencionado, temos duas linhas:
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 | +--------+----------+----------------------+-------------------------------+-------------------------------+
Ao configurar a condição, usaremos uma chave estrangeira (não obrigatória) para garantir que a próxima pergunta exista. Um valor nulo é usado para um caminho que não é possível ou, se nenhuma próxima pergunta for especificada, para encerrar condicionalmente a pesquisa.
Eu colori as tabelas que foram criadas na Parte 1 da série de artigos em amarelo , as tabelas adicionadas na Parte 2 em laranja , e a tabela recém-adicionada em verde para que seja mais fácil ver as adições.
Conclusão
Nenhuma das soluções descritas para gerenciar etapas condicionais por meio de uma pesquisa é o sistema definitivo baseado em regras, mas um dos meus objetivos é manter as coisas simples e diretas. Permitindo flexibilidade sem sobrecarregar as coisas em complexidade. E, repito, você pode ter outros requisitos. Identifique suas necessidades; implementar ou adaptar o que você precisa. Acredito fortemente na reutilização e não na reinvenção da roda.
Agora começamos a implementar as melhorias que foram discutidas nas partes 1 e 2 desta série de artigos.
Nos próximos artigos, adicionarei suporte para esses recursos:
- Administração das pesquisas
- Relatórios e análises
