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.
 * Survey may be triggered by a variety of actions, including rating an article, creating an account, editing and article/talk page/userpage (which could each correspond to a different survey), etc.
 * (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.
 * Researchers are given a method to create/receive regular data dumps
 * Researchers are given a dashboard to view and sort data (might not be needed if other tools are sufficient to get the job done)

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. Survey should have anti-spamming functionality (e.g., one one survey from each IP/account) User should be able to save surveys and return to later (this is a Phase 2 feature for longer surveys.) The same survey may be given at different points in time (e.g., to enable the tracking of attitudinal metrics over time). Survey extension should accommodate standardized surveys while enabling analysis to be run on specific instances (e.g, specific points in time).
 * Special page rendering and processing
 * Dynamic rendering
 * API processing
 * Anti-spamming
 * Saving surveys
 * Survey standardization

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.

Data Integration - User Accounts
Survey data should be associated with user accounts. For example, if there is a survey that asks for gender, researcher should be able to use this information to do edit history analysis based on gender (e.g., edit histograms by gender).