Creating Headings and Text Content
After setting up the basics of a survey in 'Create Survey', the next step is to design the layout and add sections/questions. To do so, users must first be on the Survey Display page - this is the page they are taken to after first creating a survey. On this page, underneath the basic survey details, is a row of tabs. To start designing the survey layout and adding questions/sections, users should click on the Questions tab, which is where they will see any Questions, Headings and Text elements, along with the structure of their survey, represented as a tree diagram.
To add new items, users can right click on a node of the tree diagram and choose the applicable option. Right-clicking on the 'Questions' heading under the Questions tab reveals the following options.
The function of each of these options is outlined below:
We will start by defining some Headers and Introduction Text for our example survey. Right-click on 'Questions' and choose 'Add Header or Text'. Then, when the edit screen appears, choose 'Header 1' to add a heading to our survey.
The Content box will change depending on what is selected for the Type to give users more control over the presentation of the content. Choose 'Text' and we will add some introduction text to our Survey
Note: I have chosen to style my text here for the introduction. You will see this a lot through the Survey module. You can either style up the text directly when you create it, or you can utilise the styles defined in your template to control the look of your survey. If you are not given the option to format the content when creating it, then it is solely governed by the survey template. See the Using Survey Templates article to learn more about using styles. I have left the survey template styles fairly basic, and chosen to style the text here.
Creating Questions
Questions are created in the Questions tab on the Survey Display page. As a user creates questions, they will be displayed under the Questions tab in a tree diagram, providing an idea of the layout of the survey that is being created.
The first step in adding a question to a survey is to right click on the 'Questions' heading underneath the Questions tab. This enables users to add a section and then add questions to that section; to add a question group; or to simply add an individual question (either on its own or to an existing section of the survey). If adding a question, click 'Add Question' from the drop down list.
Users will then be presented with the following screen:
On the Question Details screen, users can make all sorts of decisions about the look, feel, and type of question. These options are outlined below:
Question Text is where users can customise the question in their survey. It uses a rich text editor, and when a mouse is hovered over it, a little menu appears with options like bold, colours, and so on, so users can customise the question text.
Question Suffix: can be used to include a comment related to that question. For example, “Service Name may not be the same as Legal Trading Name”.
Question Help: can be used to provide help content to a user. For example, to explain something in more detail and only have it visible when a mouse is hovered over the little help icon it that is drawn on the survey if something is included in this section.
Internal Labels: - If users wish to use reporting tools, such as Crystal Reports, to create reports for their surveys, then they should use the Internal Labels field to give each question a succinct, logical name, which can be easily identified in Reporting Views and thus used in Crystal Reports. The Reporting Views for a survey allow users to easily work with the survey when creating reports, and are generated when the survey is published. The Survey Name and Section Name will help when identifying the Reporting Views related to a survey.
Default From Fields: This is one the most powerful features of the ChilliDB Surveys module as it allows users to default information from within ChilliDB into the survey itself. Information can be defaulted from either the Contacts or Organisations levels of ChilliDB, and nearly all fields in these modules can be used as default information in a survey.
In our example, we will default the question 'Your Service Name' to the Organisation Name field in ChilliDB, so when the survey responder looks at their survey, their Organisation Name will be pre-filled.
Response Type: When defaulting a question to draw information from ChilliDB fields, which we are in this case, the rest of the question specifics will be locked down. If the field in ChilliDB is a text field, then ChilliDB Survey will not let you change the Response Type (the field / data type for your Question) to something like a date, as that would not make sense and could create data quality issues. ChilliDB will take care of this for you. ChilliDB will also set properties, such as Minimum Number of Characters, and Maximum Number of Characters, along with Response Required. In our example, we can see this has been done, to align with the fields in ChilliDB, to again ensure the data quality of information being entered into ChilliDB.
Most of the Response Types above are logical, but some are special, for example:
File: allows respondents to attach one or more files to their survey response.
Live System Data: Sometimes users might want to have the survey link to an actual contact or organisation in ChilliDB, rather than have plain text fields to enter a name. Choosing this option will let the survey responder perform a search to find a contact or organisation.
When selecting one of these options, users will be asked to choose a Data Source, similar to when creating custom fields.
Formula: Users can construct a formula to calculate something based on information supplied by the survey respondent, and the Formula field will present the information in the survey – an example may be a score for something, or a GST calculation.
Auto Merge On Submission: Allows users to decide on a merge strategy for each question which has been defaulted from ChilliDB information. A decision can be made if the question is merged back to the ChilliDB field automatically when a survey respondent submits their survey, or if the user reviews the survey response first and then chooses to merge it manually if necessary. Automatic merge only occurs when the survey response is submitted, and not when it is saved. Auto Merge is a separate license, so if users do not yet have this license, then they will not see this option appear your ChilliDB. To obtain the license, contact the ChilliDB HelpDesk via helpdesk@chillidb.com
Response Required: This controls if the question is mandatory or not for the survey responder.
Display Annotation Field: This allows users to capture additional related information in an annotation field, which will be displayed to the user as part of the question. For example, your question could be, “If you answered 'No', please explain” and then the Annotation field could be used to capture that explanation. Set if this question is a required field, or if the question needs a mechanism for recording an additional 'Annotation' text, or even for uploading a file.
Read Only: This field is useful when defaulting information from ChilliDB, and users would like to only display a value without allowing a survey respondent to change it. An example of this might be the service name – we would like it displayed, but not changed. Read only questions are also useful for Visibility Filters, Cross Validation, and sources of data for formula fields.
Visible: This allows users to bring information into the survey through defaulting for use in Visibility Filters, Cross Validation, and sources of data for formula fields, but not have it shown to the survey respondent in the survey.
Answer Field Position: Allows users to set the position of the answer field in relation to the question text.
Now that we have completed a question, we can either create another question immediately after this one by selecting Next Question, or we can simply save the current question and return to the survey overview screen by selecting 'Finish' button.
Creating Question Groups
Sometimes users may wish to ask several questions which share a common set of choice values. In this case, rather than creating each question individually, with a choice response type, you can create a single Question Group item for these questions.
For example, users might be looking to capture something like this:
In order to create a Question Group item, users should select 'Add Question Group' from the drop-down list that becomes available when right-clicking on the Question heading in the Question tab. They will then be presented with the following screen:
The following detail needs to be added to create the Question Group item:
1. Add text in the Title to define the question.
2. Select the Type. ChilliDB will default to 'Static' answers. When you choose 'Dynamic', it is similar to using 'Default From' on simple questions - users don’t get to choose alternative options, as outlined below:
The subsequent items in this section of this article only apply to Static question groups. Users can add a static question group, and then each question in that question group can be defaulting from somewhere else.
3. Users can select the choice values for the answer within the Choice Items section. With these choice values, users can add a new choice; edit or delete existing choices; and arrange choice order.
4. Users can add a set of questions which will make use of the Choice Items set above as the answer type. With these question items, a new question can be added or edited; existing questions can be deleted; default values can be assigned for each question according to the choice values defined above; and the question order can be arranged.
5. Once users have completed building their question group item, they click the 'Save' button to save the current item and return to the Survey Display screen. By adding a question or question group item into the survey, the questions section will then look similar to the tree diagram below:
Note: users can add as many Question and Question Group items into a survey as they like. In addition to the questions, there are other features that can be used to set the display/ print layout of a survey:
Dynamic Questions Groups: Allow users to default Custom Field Grid Layouts into a survey. This enables the capturing of many “child” records for your Custom Field Grid Layout through surveys. When defaulting to fields in ChilliDB, most of the things that can be changed are locked down to protect data quality.
Creating Layouts to Hold Related Questions
Users can place one or more Question or Question Group items into rows and columns, grouping them with a border, showing grid lines or a combination of these by selecting Add Layout Item from the drop-down list under the Question heading. They will then be presented with the following screen:
On this screen, users can set if they would like to have vertical or horizontal grid lines within the layout; set a colour for the grid line; the thickness of the grid lines; and how many columns per row they want to have within the layout. 'Fieldset' is an important item - it draws the box around the collection of questions in the layout to make it look nice.
Once users have completed setting their Layout Item, they click 'Save' to save the current item and return to the Survey Display screen.
The Layout Item also has the ability to add feature items, such as a question. This is done either by using the cursor to drag the chosen question into the layout section, or by adding questions to the layout section by right-clicking on the Layout Item and then selecting 'Add Question' or 'Add Question Group' from the drop-down list. In order to insert a question/ question group item, users simply need to follow the same process as when creating a question/ question group item for a survey.
Users can also create this layout recursively, which means they create a layout within a layout. There is no limit on how many recursive depths that can be had within a layout item.
Re-Sequencing Survey Elements
Once users have a number of questions, layouts, sections, and so on, in their survey, they can easily restructure the survey by dragging these items up and down in the tree diagram.
They can also drag items underneath other items to create nesting of items where ChilliDB supports it.
Note: not all elements can be nested, and ChilliDB will guide users as to what is and isn't possible.
Visibility Filters
Visibility Filters are available for Sections and Layout (from 3.2 onwards). When creating or maintaining a section or layout, users may define one or more visibility filters, which control the visibility of all questions within those sections or layouts. This is fa great option when users want to conditionally show part of a survey and have conditions based on information either entered by the survey respondent, or based on information they default into the survey itself.
An example of where this would be used is if users have a collection of questions which are defaulting information from within ChilliDB for Organisations. Your organisations have Custom Fields sections which are relevant to certain types of organisation. For example, there may be a custom fields section called 'General Practice Details' , in which information would only be collected for organisations of the type 'General Practice'. As a result, in a survey, users would only want those survey respondents who are from organisations of the type 'General Practice' to see and enter information for that part of the survey.
Users would achieve this by adding visibility filters to their survey somewhere above the section that they would like to conditionally hide. Before doing this, users need to bring the Organisation Type into their survey by defaulting it into a question so it is accessible to the survey, and thus the filters. We don’t want the Organisation Type to be modified via the survey, or even shown to the survey respondents, so we would do the following:
1) Create a Question called 'Organisation Type' and default the information from the Organisations module field called 'Type'.
2) Make the question Read Only = 'Yes' and make Visible = 'No'.
Now that we have the information needed to configure a visibility filter, we can edit our section, or create one if we don’t have one already. In this example, we have a section called 'General Practice Organisations'. We only want this survey section visible when the organisation filling in the survey is a general practice. Select the 'Add New Filter' link to create a filter and set the Question we are basing the test on to the question which holds the Organisation Type. Set the Operator to 'Is Equal' for this example. Set the Value to 'General Practice'. This will mean, that if the organisation is categorised as a 'General Practice', then this section of the survey will be visible to them.
In other words, when the conditions of the visibility filter result in a 'TRUE' test result, then the filter is active. If you have no filters, then the applicable section of a survey is always visible.
Using Operators, users can mix and match the conditionality tests to suit their purposes. If additional filters are added, the choice can be made as to how each test relates to the other, with the ability to AND / OR the tests.
Cross Validation
Cross Validation allows users to add business rules to their survey to enforce conditions which are based on information in their survey. When the conditions fail their test, then a message, which users specify, can be displayed to the user. Users can choose if the validation rule is a warning raised to the user, then acknowledged by the user, and after doing so, they can still submit their survey response; or if the condition prevents them from submitting their survey response until they correct the issue.
An example of where this would be used is if users were collecting invoices for services delivered over a quarter, and the organisation providing the service must have current accreditation for them to submit their invoice. A check of the accreditation date, which would be held in ChilliDB, could determine if their invoice submission is accepted; or force them to upload their new accreditation certificate along with their invoice.
This would be achieved by adding Cross Validation Rules based on the Accreditation Date, which would be a question with a default set to draw in that information from the Organisations record. This is exactly the same approach as using the Organisation Type in Visibility Filters above.
Once the Accreditation Date is available in a survey, users can create the Cross Validation message and rules.
The fields for Cross Validation are as follows:
Message: can be HTML formatted. This is the message presented to the user when the conditions are not met.
Cross Validation Message Location: the section of the survey for where the message will be shown if the conditions are not met. This flexibility allows users to prevent a respondent from leaving the relevant part of the survey until they correct the issue.
How this rule will be used: gives users the flexibility of having their cross validation present a warning for acknowledgment, allowing the survey respondent to accept the warning and continue without fixing it. Alternatively, it allows users to choose to enforce the rule conditions, meaning the survey respondent cannot progress any further without correcting the issue.
Select 'Save' to save the cross validation.
Now that we have the message and configuration for the cross validation created, we can specify one or more conditions. We will create a condition which checks our survey question which holds the accreditation date to make sure that it is less than the closing date for our quarter. This way, if an organisation is not accredited for the entirety of the quarter, we will require them to attach their new accreditation certificate with their invoice. Once the conditions have been created, select 'Save'.
Using operators, users can mix and match the conditionality tests to suit their purposes. If they add additional filters, they can then also choose how each condition relates to the other conditions, with the ability to AND / OR the condition. Users can have conditions which compare against constant values like we have, or they could design complex surveys which check questions against questions.