Development:Survey 2 brainstorm

This page is for collecting feature requests for a new Survey module that replaces Survey, Questionnaire and Feedback.

Module settings page

• option: allow/deny save without submission
• option: anonymous survey or named responses
• option: allow/deny record modification after submission
• option: allow/deny the read only access to submitted records (see next example)

(Example: This option should appear like:

Submitted answers are available/visible <select name="dropdown_7" size="1">

<option value="0">to all users</option> <option value="1" >to submitter only</option> <option value="2" >to submitter group only</option>

</select>

)

• option: allow/deny submitted record deletion
• custom form and css
• download of submitted records in some standard format
• option: allow access to results any time/after you've submitted/after close date/never
  • fine-grain control for result display at question level also
• type of field (char(n), text, number, alphanumeric, boolean, date, picture, file, email, url...) with type check at submit time (and number of digit check for char(n) fields).

This information may not be used at field definition time but is useful for data verification/check. (see next example)

(Example: Please, enter your card ID: _______ This field should be defined, for instance, as char(7))

• opening and closing submission dates (displayed on calendar)
• relations between tables

(Example: one record for the profile of my company one related record for each intervention request submitted by my company)

Standard module settings

• support for groups and groupings
• permission control for which roles can create surveys

Field level settings

• mandatory/non mandatory field option
• free text description field for further description and advice to the completer
• define a range of valid answers for fields allowing this (see next examples)

(Example 1: Please, enter your seniority. (limited between 0 and 50 years)

Example 2: Date of birth: (limited between 18 and 100 years ago))

• define fields default to be loaded at "new record" display time
• optional "other" text field for drop down menu/radio button/check box. (see next example)

(Example for drop down:

Where were you born? <select name="dropdown_14" size="1"><option value="1" selected="selected">Spain</option><option value="2" >France</option><option value="3" >other, please specify</option></select>  <input type="text" name="dropdown_14_other" size="10" maxlength="10" value="" />

If you choose "other" in the drop down menu the field will be enabled and become mandatory, otherwise it will be disabled. )

• define read-only fields (auto filled by the software) like, current_date, user_name, record_ID...
• option: allow access to results any time/after you've submitted/after close date/never

Fields types

Field types should be plug-ins so that they can be extended locally if required. The following list covers types which exist in at least one of the current survey modules.

• radio buttons
  • horizontal & vertical
• short text entry
• long text entry
• allocation
• checkbox
• customisable likert scale for rating
• ranking

New field types

• short date (with month and years only, to answer question like: When had you the first evidence of this disease?)
• order list. A list of available items and the answer is supposed to order them.
• time (see next example)

(Example: When do you usually take breakfast? )

Result display

• choose for a question whether to display results as
  • a table
  • a bar chart
  • a pie chart

Question management

• questions can be copied within an activity
• question sets can be created as templates for re-use
• question sets can be used across multiple courses
• questions can be re-ordered within an activity
• question sets can be combined to create a questionnaire

Uncategorised requested features

• handle more than one view_single/view_list/find/input layout (and allow this or that layout to users on the basis of capabilities).

The idea is: On the basis of capability you will access your specific layout with only a field subset. If you have this capability, you will find all the fields of the survey, otherwise you will find only a subset of them.

The same feature may be provided in the following way: At fields level definition the course creator should be allowed to mark the field "field1" as

1. visible and enabled to all
2. visible to all but enabled to users with view_field1 capability only
3. visible and enabled to users with view_field1 capability only

• allow update of submitted questionnaire as an option (not just a clean slate on the next go-round)
• allow course creator to add custom number to question inside layouts (i.e.: 1, 2, 2a, 2b, 3...) to respect questions hierarchy
• allow course creator to indent questions inside layouts to respect questions hierarchy (as it is already possible the indent of resources inside courses)
• conditional branching (see next example)

(Example:

1. Gender: <input type="radio" name="gender" value="0" checked="checked"/>F  <input type="radio" name="gender" value="1" />M
1a. How many pregnancies have you had? <select><option value="0" selected="selected">0</option><option value="1">1</option><option value="2">2</option><option value="more">more</option></select> (should be disabled when answer 1 == F)
1b. Question relevant only for males? <select disabled="disabled"><option value="aa" selected="selected">aa</option><option value="bb">bb</option><option value="cc">cc</option><option value="more">other</option></select> (should be disabled when answer 1 == M)

)