From MediaWiki.org
Jump to navigation Jump to search

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.

Use cases[edit]


  • 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.
  • Users are targeted based on their unique ID markers like login information or IP address. Instead of blanketing the site with links to the survey that will skew the sample in favor of those that read and edit the Wikipedia more frequently, this approach would increase the odds for those who are not very regular editors or readers.


  • Researchers provide a developer with survey specifications which are turned into software. Critical to support in version 1.0.
  • In case the survey has quotas that need to be met, researchers should provide the developers with specifications to close the survey for groups after their quota is met.
  • 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 have the option of exporting raw data into different formats for analysis like .sav or .csv files.
  • 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 dashboard to view and sort data (integration with other tools?)



Special page rendering and processing

Surveys should be able to be accessed using and submitted through a MediaWiki special page.

Dynamic rendering

Surveys should be able to be rendered into any HTML element on the client side.

API processing

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)

Saving surveys

User should be able to save surveys and return to later (this is a Phase 2 feature for longer surveys.)

Survey standardization

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


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


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[edit]

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