In the summer of 2020 I started a new project with the aim of enabling users to create their own surveys. Surveys would be viewable in a central location for users to view and complete. It was ultimately never completed, but here are some notes about the development phase. I have also included some of the concept diagrams and screenshots that I kept.
There are many external services that offer survey functionality, but the goal was to integrate this within the existing XenForo framework. Polls have existed as a core feature in XenForo (and in many discussion forum software) for a while, but I have always felt they don't reveal much. The goal was also to implement this feature in a way that made sense to me, and to remove as many unnecessary features as possible. I wanted to start simple and add complexity later. But I wanted to develop the add-on such that complexity could be added easily later on. I would later find that with each new feature, the complexity grew. I studied many different survey services (Google Forms, SurveyMonkey, LimeSurvey, to name just a few) and what each one offered. It became difficult to know where to limit the feature set.
I also consulted online survey tool designed for Academic Research, Education and Public Sector organisations to discover what data researchers commonly need to gather and to see how simple (or complex) surveys could become.
My initial thinking was to start simple and add complexity later. But even at this early stage, it was important to think about the features that might be added later. This was important when considering database design and what information we record, even if we don't yet expose it.
To start with, users could craft questions and organise them into groups of related questions (groups). Each question (child item) would be of a specific type and could be moved between each parent group as the user was constructing their survey.
A user could create a survey by selecting the Survey tab when creating a new thread or by simply creating a new Survey from a separate section (much like how Resources have an associated thread). Given the complexity involved for an author when creating a survey, I wanted to implement auto-draft saving (in case of failure when saving upon completion) and a 'save and close' feature (so authors could return to their incomplete survey later). You can see these in a later screenshot.
The diagram below is a concept of which actions would be possible. The user would be able to use the drag handles (styled as blue) on the left to move the order of groups, the order of questions, or move questions between groups. The green and red arrows document these actions, allowed and forbidden, respectively.
The concept diagram also shows plus and minus symbols intended to easily allow the user to create new groups or new questions. Naturally, the user interface parts utilise JavaScript.
From here, each question would have a specific type for the type of answer expected. These would be: short answer, paragraph, multiple choice grid (checkbox), single choice grid (radio), checkboxes, dropdown, linear scale (scoring), date, time.
Below are my handwritten notes for what question types should do and what options there should be. There are notes for whether the question is required and whether there should be any response validation. There is a note at the bottom regarding an option to randomise questions in a group.
I began building the "creation" page and adding in functionality, or at least mapping it out so it was easier to visualise. You will notice (below) that the implementation retains many of the design elements from the hand drawn concept (above), such as drag handles and plus/minus icons.
At this early stage I was considering how this tool might be used. Certain surveys have ethical considerations, for example, and even if this add-on would not be intended for this particular use case, I had to account for it. Survey authors may wish to specify that a user must read and confirm a message prior to commencing the survey. This was implemented as a checkbox below the main description. Another consideration was anonymous responses and the option not to record the user in question. This would have lead to a unique challenge since all content within XenForo is mapped with a user ID.
I later implemented a tabbed interface, whereby questions and groups were kept separate from other configurable features such as branching and further options.
Question branching would operate similar to how it does in other services that offer services; whereby, if certain conditions are met (such as a particular answer is given), certain actions are performed (such as skipping certain future questions from being displayed entirely).
I had the basic database relationships mapped out and I knew which data I needed to record for each survey. This would help to generate an initial "route" upon creation of the survey to be used upon initialisation of the survey.
Some questions that arose at this stage were: can a survey be edited once it goes live? What should happen if the survey is edited or changed while a user is taking part in the survey? One way of overcoming these problems would be to allow editing of the textual parts of the survey, but not allow any restructuring, reordering, or changing of the question types. If a survey author wishes to make drastic and significant changes to a survey that had already gone live, their only option would be to remove the survey (or unpublished it, so it could still be referenced) and create a new one.
There are many external services that offer survey functionality, but the goal was to integrate this within the existing XenForo framework. Polls have existed as a core feature in XenForo (and in many discussion forum software) for a while, but I have always felt they don't reveal much. The goal was also to implement this feature in a way that made sense to me, and to remove as many unnecessary features as possible. I wanted to start simple and add complexity later. But I wanted to develop the add-on such that complexity could be added easily later on. I would later find that with each new feature, the complexity grew. I studied many different survey services (Google Forms, SurveyMonkey, LimeSurvey, to name just a few) and what each one offered. It became difficult to know where to limit the feature set.
I also consulted online survey tool designed for Academic Research, Education and Public Sector organisations to discover what data researchers commonly need to gather and to see how simple (or complex) surveys could become.
My initial thinking was to start simple and add complexity later. But even at this early stage, it was important to think about the features that might be added later. This was important when considering database design and what information we record, even if we don't yet expose it.
To start with, users could craft questions and organise them into groups of related questions (groups). Each question (child item) would be of a specific type and could be moved between each parent group as the user was constructing their survey.
A user could create a survey by selecting the Survey tab when creating a new thread or by simply creating a new Survey from a separate section (much like how Resources have an associated thread). Given the complexity involved for an author when creating a survey, I wanted to implement auto-draft saving (in case of failure when saving upon completion) and a 'save and close' feature (so authors could return to their incomplete survey later). You can see these in a later screenshot.
The diagram below is a concept of which actions would be possible. The user would be able to use the drag handles (styled as blue) on the left to move the order of groups, the order of questions, or move questions between groups. The green and red arrows document these actions, allowed and forbidden, respectively.
The concept diagram also shows plus and minus symbols intended to easily allow the user to create new groups or new questions. Naturally, the user interface parts utilise JavaScript.
From here, each question would have a specific type for the type of answer expected. These would be: short answer, paragraph, multiple choice grid (checkbox), single choice grid (radio), checkboxes, dropdown, linear scale (scoring), date, time.
Below are my handwritten notes for what question types should do and what options there should be. There are notes for whether the question is required and whether there should be any response validation. There is a note at the bottom regarding an option to randomise questions in a group.
I began building the "creation" page and adding in functionality, or at least mapping it out so it was easier to visualise. You will notice (below) that the implementation retains many of the design elements from the hand drawn concept (above), such as drag handles and plus/minus icons.
At this early stage I was considering how this tool might be used. Certain surveys have ethical considerations, for example, and even if this add-on would not be intended for this particular use case, I had to account for it. Survey authors may wish to specify that a user must read and confirm a message prior to commencing the survey. This was implemented as a checkbox below the main description. Another consideration was anonymous responses and the option not to record the user in question. This would have lead to a unique challenge since all content within XenForo is mapped with a user ID.
I later implemented a tabbed interface, whereby questions and groups were kept separate from other configurable features such as branching and further options.
Question branching would operate similar to how it does in other services that offer services; whereby, if certain conditions are met (such as a particular answer is given), certain actions are performed (such as skipping certain future questions from being displayed entirely).
I had the basic database relationships mapped out and I knew which data I needed to record for each survey. This would help to generate an initial "route" upon creation of the survey to be used upon initialisation of the survey.
Some questions that arose at this stage were: can a survey be edited once it goes live? What should happen if the survey is edited or changed while a user is taking part in the survey? One way of overcoming these problems would be to allow editing of the textual parts of the survey, but not allow any restructuring, reordering, or changing of the question types. If a survey author wishes to make drastic and significant changes to a survey that had already gone live, their only option would be to remove the survey (or unpublished it, so it could still be referenced) and create a new one.