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.


 * Error recovery - error message at minimum, preserving status until re-connected, keep retrying?

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.


 * The format of the email address should be validated and a simple error message displayed if not valid.

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

Article linking

 * Articles near me 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
 * Ongoing photo contributions can be treated as Evergreen
 * Contest refers to a specific engagement limited by time and location
 * A screen for defining the contest parameters and user permissions needs to be defined


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


 * Ratings - 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
 * Users can rate photos from the entry point in the Nearby view, as well as after submitting a photo for an article


 * Personal Stats - User can see his or her stats showing number of photos submitted and overall rating per Contest or Evergreen, and can see the rating of each photo


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