Extension:SimpleSurvey/Specifications

This document provides a specification from which the SimpleSurvey extension can be redesigned and rewritten to support a more broad range of use cases and support simpler reuse.

Users

 * Users are sent to a special page which contains a survey they can complete and then return to their prior location.
 * Users are shown a modal dialog which contains a survey they can complete and then close.
 * (other use cases?)

Researchers

 * Researchers provide a developer with survey specifications which are turned into software. Critical to support in version 1.0.
 * Researchers are given a user interface where they can view and/or download survey response data. Ideally supported in version 1.0, possibly supported in version 2.0 or an adjacent system.
 * Researchers are given a user interface to draft/create a survey. Possibly supported in version 2.0 or an adjacent system, localization poses a challenge but could be solved for.

Access
Surveys should be able to be accessed using and submitted through a MediaWiki special page. Surveys should be able to be rendered into any HTML element on the client side. Surveys should be able to be submitted using a MediaWiki API method.
 * Special page rendering and processing
 * Dynamic rendering
 * API processing

Configuration

 * Creation
 * Surveys should be able to be created by adding a simple extension which provides i18n messages and hooks into the survey extension to provide the survey configuration data.


 * Access
 * Surveys should be configurable to be accessible from logged in or anonymous users, or both.
 * Survey should be configurable to be accessible from particular language projects; i.e. only Latin alphabet language projects, only Hindi Wikipedia.
 * Surveys should be configurable to be accessible to users accessing the Internet/Wikipedia from a particular region; i.e. users living in the Bay Area.
 * Data collection
 * Facilities for automatically gathering information about a user’s computer, browser and general location should be available on the client side.
 * Surveys should be able to execute any number of hooked in functions at the time of submission to collect and store additional information; i.e. how many edits the user has.

Logging
Survey access should be logged to provide statistics about how many times a survey has been opened, canceled and completed with persistent user information to track a user’s behavior over time; i.e. a user opened then canceled but then later opened and completed or users average 5 minutes to complete the survey, etc.