Module definition language requirements

Requirements

The things we need from a survey/cognitive task module definition language are:

1. The capability to represent all of the survey question types that are available in LimeSurvey.

2. The ability to represent arbitrary conditional and looping constructs in surveys (and to deal with the resulting optional or multiple data values).

3. A modular structure that allows us to reuse modules within other modules, to build collections of modules, etc.

4. The capability to construct parameterised modules, i.e. modules that take input parameters to modify their behaviour.

5. The capability to define arbitrary functions to calculate values for display or further processing depending on user inputs (for example, calculating BMI from height and weight).

6. The capability to represent welcome/finished/instruction/description texts and the machinery in the "survey running" code to access help information at any appropriate point in the survey.

7. Simple data collection semantics (for internal use and for the clinics) to make data export and statistical post-processing easy. Most psychodiagnostics tools use their own naming conventions for variables and answer codes and we should make it easy to support these.

8. Good support for internationalisation and language translation.

9. Good support for multimedia assets (images, sound, video) that can be embedded in survey pages, questions and for use as a "cover image".

10. Support for representing cognitive tests (either using JavaScript, or Flash or some other embedding technology). Very vague at the moment since this isn't something we need for the first 6 month milestone.

One thing I'm not thinking about too much at the moment is the "statistics" modules: all of this is focused on the 6-month "surveys" goal that we have. Hopefully the module DSL will be general enough that it won't be too hard to extend it to represent wrappers around statistical analyses later on.

Module metadata

These are things that need to be stored with a module for display in the Module Market and for managing certain aspects of how modules are scheduled and handled, but which are really just static data that can go in a simple "module description" block at the top of the module definition.

1. Module - Shortname (used for routing / URL) - or do we do that from 'Module Name'?

2. Some states: Under development (with maybe progress indicators) / Published / Private (just for me or my clinic)

3. Tags (Depression, sleep and so on.)

4. (Co-)Author of this module

5. scheduler settings: The capability to determine the default 'scheduler settings': unique gathering, every evening, at events.

6. Does this module have some 'royalty obligation' - does this module have questions from psychodiagnostic tests in that need licences?

Infrastructure issues

By "infrastructure issues", I mean things that are more to do with how the Module Market works and how surveys are scheduled and run than the module DSL itself (there's some overlap, obviously).

1. Module Market stuff (sure - later): price

2. Allowing comments / ratings (We probably don't want to restrict that.)

3. Flags: Should a patient should see the statistics / results?

4. Mega surveys: Sometimes it is useful to pause/resume surveys.