Development:Survey 2 brainstorm: Difference between revisions

From MoodleDocs
m (→‎Fields types: Replaced "fields" with "questions")
m (Text replacement - "class="nicetable"" to "class="wikitable"")
 
(20 intermediate revisions by 3 users not shown)
Line 1: Line 1:
This page is for collecting feature requests for a new Survey module that replaces Survey, Questionnaire and Feedback.
This page is for collecting feature requests for a new Survey module that replaces Survey, Questionnaire and Feedback.


==Module settings page==
==General features of the Module==
*option: allow/deny save without submission
* translate previously built survey1, feedback and questionnaire at installation time
*option: anonymous survey or named responses
* upload exported feedback or questionnaires (survey1 doesn't export questionnaires templates)
*option: allow/deny record modification after submission
* save instances of survey2 as a template to reuse it or export it
*option: allow/deny the read only access to submitted records (see next example)
* import saved survey2 templates
(Example: This option should appear like:
* support for groups and groupings
<code>
* custom user survey2 page layout (custom html and css, as it already is in database module)
<div>Submitted answers are available/visible <select name="dropdown_7" size="1">
* download of submissions in txt, xls and ods
<option value="0">to all users</option>
* conditional branching
<option value="1" >to submitter only</option>
* handle more than one input form layout (and find a way to allow this or that layout to this or that user).
<option value="2" >to submitter group only</option>
* order survey fields in editing mode
</select></div>
* group fields in the page layout with fieldset
</code>
* relations between tables (Example: one record for the profile of my company one related record for each intervention request submitted by my company)
)
* email submissions to students/teachers/both/none
*option: allow/deny submitted record deletion
* email submissions to address specified in a designated question field (for surveys not requiring login)
*custom form and css
* for text fields, simple data checking ('must be numeric', 'must contain X character', 'must have exact length n', etc.)
*download of submitted records in some standard format
* full web accessibility features to the same level as elsewhere in Moodle e.g. labels on text fields, fieldsets on groups of radio buttons & checkboxes.
* option: allow access to results any time/after you've submitted/after close date/never
* gradebook integration (to allow simple polls to control conditional activities)
** 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)
==Instance settings page==
* Access section: 20 types of survey, distinguished by:
:-> ppl who is allowed to R/O,
:-> ppl who is allowed to R/W,
:-> ppl who is allowed to delete a record
The reationale is: once a record has been submitted by a user, who is allowed to see it (R/O access)?, who is allowed to edit it (R/W access)?, who is allowed to delete it?


(Example:
Combining all the options the come out 20 cases are defined as follows where:
Please, enter your card ID: _______
:ALL means, all the people accessing the survey;
This field should be defined, for instance, as char(7))
:GROUP means people belonging to the group of the user who submitted the record;
*opening and closing submission dates (displayed on calendar)
:OWNER is the user who submitted the record;
*relations between tables
:NONE is none.
(Example:
{| class="wikitable"
one record for the profile of my company
|-
one related record for each intervention request submitted by my company)
! type
! R/O
! R/W
! delete
|-
| 1
| ALL
| ALL
| ALL
|-
| 2
| ALL
| ALL
| GROUP
|-
| 3
| ALL
| ALL
| OWNER
|-
| 4
| ALL
| ALL
| NONE
|-
| 5
| ALL
| GROUP
| GROUP
|-
| 6
| ALL
| GROUP
| OWNER
|-
| 7
| ALL
| GROUP
| NONE
|-
| 8
| ALL
| OWNER
| OWNER
|-
| 9
| ALL
| OWNER
| NONE
|-
| 10
| ALL
| NONE
| NONE
|-
| 11
| GROUP
| GROUP
| GROUP
|-
| 12
| GROUP
| GROUP
| OWNER
|-
| 13
| GROUP
| GROUP
| NONE
|-
| 14
| GROUP
| OWNER
| OWNER
|-
| 15
| GROUP
| OWNER
| NONE
|-
| 16
| GROUP
| NONE
| NONE
|-
| 17
| OWNER
| OWNER
| OWNER
|-
| 18
| OWNER
| OWNER
| NONE
|-
| 19
| OWNER
| NONE
| NONE
|-
| 20
| NONE
| NONE
| NONE
|}


=== Standard module settings ===
* option: allow/deny save without submission (save and restart)
* option: anonymous survey or named responses
* option: allow access to records any time/after you've submitted/after close date/never
* opening and closing submission dates
* number of maximun allowed submission
* option whether to show results immediately after submission, or a thank you message with link to results.


* support for groups and groupings
==Field level settings==
* permission control for which roles can create surveys
* 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.


==Field level settings==
(Example: Please, enter your card ID: _______ This field should be defined, for instance, as char(7))
*mandatory/non mandatory field option
* option: mandatory/non mandatory field
*free text description field for further description and advice to the completer
* free text description field for further description and advices to the completer
*define a range of valid answers for fields allowing this (see next examples)
*define a range of valid answers for fields allowing this (see next examples)
(Example 1:
(Example 1:
Line 55: Line 167:
If you choose "other" in the drop down menu the field will be enabled and become mandatory, otherwise it will be disabled.
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...
* custom question numbers
* option: allow access to results any time/after you've submitted/after close date/never
* question name to name columns header in the downloaded document


==Question types==
==Question types==
Line 62: Line 174:
Question 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.
Question 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
* radio buttons (horizontal & vertical display)
** horizontal & vertical
* short text entry
* short text entry
* long text entry
* long text entry
* allocation
* checkbox
* checkbox
* drop down menu
* customisable likert scale for rating
* customisable likert scale for rating
* ranking
* date (Example: When were you born?)
 


===New question types===
===New question types===
*short date (with month and years only, to answer question like: When had you the first evidence of this disease?)
* 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
*time (see next example)
 
(Example:
(Example:
When do you usually take breakfast?
When do you usually take breakfast?
)
)
* "static text"/"read only" fields (auto filled by the software) like, current_date, user_name, record_ID, counter...
* allocation (Drag and drop)
* ranking


==Result display==
==Result display==


* report per survey, per user and per question
* report about non-respondent users
* choose for a question whether to display results as
* choose for a question whether to display results as
** a table
** a table
Line 91: Line 204:


* questions can be copied within an activity
* questions can be copied within an activity
* question sets can be created as templates for re-use
* question sets can be created as templates for re-use [maybe later]
* question sets can be used across multiple courses
* question sets can be used across multiple courses [maybe later]
* questions can be re-ordered within an activity
* questions can be re-ordered within an activity
* question sets can be combined to create a questionnaire
* question sets can be combined to create a template
 
* questions can be deleted from an activity, but there should be an "are you sure" check first.
==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
#visible and enabled to all
#visible to all but enabled to users with view_field1 capability only
#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: <code><input type="radio" name="gender" value="0" checked="checked"/></code>F  <code><input type="radio" name="gender" value="1" /></code>M
1a. How many pregnancies have you had? <code><select><option value="0" selected="selected">0</option><option value="1">1</option><option value="2">2</option><option value="more">more</option></select></code> (should be disabled when answer 1 == F)
1b. Question relevant only for males? <code><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></code> (should be disabled when answer 1 == M)
)


==Answer Piping & Conditional Questions==
==Answer Piping & Conditional Questions==

Latest revision as of 13:24, 14 July 2021

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

General features of the Module

  • translate previously built survey1, feedback and questionnaire at installation time
  • upload exported feedback or questionnaires (survey1 doesn't export questionnaires templates)
  • save instances of survey2 as a template to reuse it or export it
  • import saved survey2 templates
  • support for groups and groupings
  • custom user survey2 page layout (custom html and css, as it already is in database module)
  • download of submissions in txt, xls and ods
  • conditional branching
  • handle more than one input form layout (and find a way to allow this or that layout to this or that user).
  • order survey fields in editing mode
  • group fields in the page layout with fieldset
  • relations between tables (Example: one record for the profile of my company one related record for each intervention request submitted by my company)
  • email submissions to students/teachers/both/none
  • email submissions to address specified in a designated question field (for surveys not requiring login)
  • for text fields, simple data checking ('must be numeric', 'must contain X character', 'must have exact length n', etc.)
  • full web accessibility features to the same level as elsewhere in Moodle e.g. labels on text fields, fieldsets on groups of radio buttons & checkboxes.
  • gradebook integration (to allow simple polls to control conditional activities)

Instance settings page

  • Access section: 20 types of survey, distinguished by:
-> ppl who is allowed to R/O,
-> ppl who is allowed to R/W,
-> ppl who is allowed to delete a record

The reationale is: once a record has been submitted by a user, who is allowed to see it (R/O access)?, who is allowed to edit it (R/W access)?, who is allowed to delete it?

Combining all the options the come out 20 cases are defined as follows where:

ALL means, all the people accessing the survey;
GROUP means people belonging to the group of the user who submitted the record;
OWNER is the user who submitted the record;
NONE is none.
type R/O R/W delete
1 ALL ALL ALL
2 ALL ALL GROUP
3 ALL ALL OWNER
4 ALL ALL NONE
5 ALL GROUP GROUP
6 ALL GROUP OWNER
7 ALL GROUP NONE
8 ALL OWNER OWNER
9 ALL OWNER NONE
10 ALL NONE NONE
11 GROUP GROUP GROUP
12 GROUP GROUP OWNER
13 GROUP GROUP NONE
14 GROUP OWNER OWNER
15 GROUP OWNER NONE
16 GROUP NONE NONE
17 OWNER OWNER OWNER
18 OWNER OWNER NONE
19 OWNER NONE NONE
20 NONE NONE NONE
  • option: allow/deny save without submission (save and restart)
  • option: anonymous survey or named responses
  • option: allow access to records any time/after you've submitted/after close date/never
  • opening and closing submission dates
  • number of maximun allowed submission
  • option whether to show results immediately after submission, or a thank you message with link to results.

Field level settings

  • 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.

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

  • option: mandatory/non mandatory field
  • free text description field for further description and advices 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. )

  • custom question numbers
  • question name to name columns header in the downloaded document

Question types

Question 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 display)
  • short text entry
  • long text entry
  • checkbox
  • drop down menu
  • customisable likert scale for rating
  • date (Example: When were you born?)

New question types

  • short date (with month and years only, to answer question like: When had you the first evidence of this disease?)
  • time

(Example: When do you usually take breakfast? )

  • "static text"/"read only" fields (auto filled by the software) like, current_date, user_name, record_ID, counter...
  • allocation (Drag and drop)
  • ranking

Result display

  • report per survey, per user and per question
  • report about non-respondent users
  • 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 [maybe later]
  • question sets can be used across multiple courses [maybe later]
  • questions can be re-ordered within an activity
  • question sets can be combined to create a template
  • questions can be deleted from an activity, but there should be an "are you sure" check first.

Answer Piping & Conditional Questions

  • Allow follow on questions related to the previous.
  • Do You Smoke? Yes/No If Yes is selected a conditional question appears, How Many per Day, if No is selected move on to question 6 appears


  • Answer Piping such as:
  • Q1 Which dog breed do you prefer?
  • Labrador
  • Spaniel
  • Collie
  • Other


  • Q2 In question 1 you stated you prefer the (Q1 Answer) as a breed, what do you like about it. [Where (Q1 Answer) is replaced with the chosen answer such as 'Labrador'
  • Temperament
  • Looks
  • Colour
  • Other