General User Survey/Implementation

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search

Functional and technical design issues regarding the implementation of the General User Survey[edit]

Before the survey form (or set of forms) can be implemented a lot of issues need to be addressed.

This page aims at that: to discuss all specifics that influence implementation.

List of proposed functional requirements[edit]

  • Authentication: As this survey is really about Wikimedia editors, not users in general (reminder: change article titles) we will need to check whether a submitter is indeed a regular contributor to one or more Wikimedia projects, so that only confirmed Wikimedia editors submit the form and so that they do this only once.
  • Anonimisation: No way should a user response be traceable to a specific known user.
  • Flexibility: Ideally questions asked in the questionnaire can be added or modified until the last moment. Last minute changes or text-bug-fixes during the survey (kept at a bare minimum as this distorts results) only by moderators.
  • Output: we need a coding system to make results processable by statistics script and language independant. For instance a question like 'Where do you live' should offer a selection list, not an edit box for free format response. Also the script should not store a country name but a language independant country index number.
  • Comments Facility to add (question specific) comments or (per question) links to (question specific) talk page(s). Storing comments in a database allows anonimized display, but means extra coding.
  • Navigation: A menu or drop down box can be generated from the input file that lists all languages in which the survey is available and from which the user selects the language of choice.
  • Validation: The form could do some validation: maybe some questions should be answered (not sure about this)

List of proposed technical requirements[edit]

  • Language: The survey form(s) are best coded in PHP. This makes integration into the Mediawiki at a later stage (should this ever be desired) so much easier.
  • Authentication: in order to implement authentication a user name and password need to verified agaianst the Wikimedia user tables. This same functionality is needed (and presumably already automated) for existing official election procedures (like the board elections). We will have to dicuss this with Mediawiki developers. Ideally that code can be reused.
  • Anonimisation
  • Input driven layout and content: The PHP code should be structured in such a way that the actual questionnaire is built dynamically from a language specific input file.

This way last minute updates are possible which do not effect the script. Or perhaps better: all languages are kept together in one input file with one section per question and all translations preceded by a language code, this facilitates translation and allows oversight. Make no assumptions on text size. The test file may use English texts. Other languages may use much shorter or longer texts. The texts from the input file may contain basic html formatting like itaic and bold tags.

  • Layout: The input file from which the questionnaire is built also prescribes the windows control to be used (radio buttons, check box, edit box) and the form of output desired.
  • Unicode: Use unicode codepage for html output.
  • RTL: Some languages needs right to left presentation (Hebrew, Arabic,...). This is easily done in html, but needs to be specified in the input file.
  • Defaults: Radiobuttons should be all 'unselected' to start with. Too often polls on the web show the fist choice selected by default.