MobileFrontend/Photo upload/Functional requirements

General

 * Enable an easy, mobile-friendly mechanism for uploading photos from our apps and mobile site (where possible)


 * Universal device coverage - ensure lesser experiences on lesser devices, including S40 and any feature phone that can support a data connection


 * Simplify licensing and reduce typing


 * Warn of data charges and make WiFi a clear option


 * Basic version re-purposes the existing Upload Wizard


 * Advanced version uses an article or other front-end as the starting point of the workflow


 * Improved photo handling in the mobile site is a pre-requisite; photo handling in the apps is a new function

Basic Workflow
The Basic Workflow is a mobile-friendly version of the Upload Wizard on Commons, with two different starting points:
 * A menu command in the Wikipedia mobile site or app
 * The sharing function associated with the photo gallery on Android devices
 * Login is required and the user will be directed to login upon initiating the workflow, if he/she is not already logged in

Sharing

 * From the gallery view on Android devices, the share function will show Wikipedia or Wikimedia Commons as a destination. This will then launch the mobile upload process defined as the Basic Workflow.

Photo selection

 * Using the gallery or thumbnail view on a device (or emulating the native one), the user can select a single image easily, to view full-screen and to mark for upload.


 * In v1, the workflow will be limited to a single image.


 * In later versions, a method for selecting multiple images will be enabled.

Upload

 * Once an image is selected, the upload button becomes active and the user can press it to begin uploading.


 * Before uploading starts, a warning screen notifies the user of the total amount of data that must be transferred, and present several options, such as canceling, going back to selection, continuing, checking WiFi connections, and saving the current selection for uploading later.

Licensing

 * During the upload, the screen shows a progress bar and present the license options, based on a work created by the user or not created by the user.


 * The license options could be further customized for a given purpose, such as Wiki Loves Monuments, which may require specific licensing in different countries.

Description

 * Once upload is done, a thumbnail of the image is displayed and options are presented for title of the file, description in any language, and category(ies). Title is pre-filled as the file name, category is pre-filled with the default category (see next) and the date of creation is shown. Therefore, the only field the must be edited is description.


 * The pre-filled category will be defined according to source of the upload, meaning Android or iOS app or Android or other browser. Ideally, some further info such as OS version number and browser type can also be included.

Use

 * Since use on a mobile device is not currently convenient, an email can be sent to the user with a record of the upload and the text or URL for including the image in a wiki or HTML page.


 * The user's email address must be part of the user's profile, and if it is not, the user can type it into a field and be given the option to include that email address in his or her profile.

Advanced Workflow
This workflow uses a Wikipedia article or other front-end as the starting point.
 * "Articles nearby me" and "Articles near this article" are pre-requisite functions for the Advanced Workflow
 * This workflow uses all aspects of the Basic Workflow except the following:

Article linking

 * Articles near me and articles near this article can highlight articles missing photos and offer a simple way to initiate a contribution by the user.


 * Some ID is required to link a photo to an article. This ID must stay with the photo throughout the curating process on Commons.


 * When the photo is put into the intended or originating article, the ID can be used to easily identify the article.

Pre-filling wizard

 * Article name and ID
 * Language - pre-selected for the description field
 * Item name and/or ID - specific to a contest or article template
 * Category - pre-filled as platform app/browser source, another pre-filled category for contest name

Use

 * The email generated at the end of the process will include:
 * Photo description info
 * Article name and ID
 * Ideally a link to the originating article
 * In addition to basic info and text to use in wiki or HTML pages

Game dynamics

 * This workflow can use two types of game dynamics: Evergreen and Contest
 * Evergreen refers to an ongoing nature, like a perpetual activity not limited by time or location
 * Contest refers to a specific engagement limited by time and location


 * Contests can be nested, meaning that there can be over-arching qualities and smaller contests within a larger one


 * Photos submitted can be viewed in a convenient grid or list of thumbnails and rated up or down or by a specific value
 * The rating ability can be limited to specific users in a specific contest
 * Users cannot rate their own photos


 * User can see his or her stats showing number of photos submitted and overall rating, and can drill down to see the rating of each photo


 * User can keep track of each photo in terms of its detailed rating and when it is added to articles