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

Language

The language setting of this workflow will depend on the language setting overall, which is an issue being addressed in Wikipedia Navigation UI. For the purposes of Photo Upload, we will assume the predominant language setting (often the same as the phone's language setting) will determine the language used thoughout the Basic and Advanced Workflows.

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 presents 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 presents the license option for work created by the user, pre-selecting that option. Alternatively, that option is remembered for that user once it is selected.

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

• It is possible that in addition to giving the user the option to cancel at this stage, there could be a "can't go farther" condition generated by non-selection of "work created by the user." This path assumes that we will not present other licensing options in this Workflow.

• License text includes the following:
  • Please provide license information for this work.
  • Note: do not upload photos of copyrighted posters, signs or covers.
  • I took this photo.
  • I, Philinje, the copyright holder of this work, irrevocably grant anyone the right to use this work under the Creative Commons:
  • ShareAlike 3.0 license (anyone may use, share or remix this work, as long as they credit me and share any derivative work under this license) [legal code]
  • Attribution 3.0 (credit me only) [legal code]
  • CC0 (release all rights) [legal code]

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

• The Title field is blank and the user must add a title which is more than 5 characters.
  • If the title is unique, it will be copied automatically into the description field (not shown to the user).
  • If the title entered by the user is not unique, the error message should include a suggested title, such as the text typed by the user plus the user's username.

• Automatically copy title into description field (not shown) upon submitting

• A freeform text field will be available for other notation, probably hidden under a link, "Other text"

• Date of creation will be extracted and saved automatically.

• Geo coordinates, when available, will be extracted from the EXIF data and saved by default (note that there is a larger policy issue surrounding this).

• The pre-filled hidden categories 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, for example:
  • Top-level category: Uploaded with mobile
  • Sub-category: Uploaded with Android browser v1.1
  • And contest name?

• Issue: Bot will issue warnings if no normal category is assigned - this can be modified after agreement with the Commons community

• For WLM, if user knows monument ID, Title can be ID of monument plus something unique like username, also category

• WLM users can add template: Wiki Loves Monuments 2012 {{Wiki Loves Monuments 2012|fr}}
  • And template: city and unique ID {{Merimee|00458}}
  • This will generate the right categories

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 should be pre-populated if it is 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 their profile (not by default).

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

Geo coordinates

• There will be another version of Photo Upload that makes use of geo coordinates in an explicit way. However, for now, the intention is to extract and save geo coordinates when available, as described above under Description.

User profile

• There should be a screen for the user to see their profile details, which include:
  • email address
  • current uploads
  • link to that user's Talk page
  • status message, like "Blocked due to repeated copyright violations."
• This screen could be linked from the Use screen and also made accessible by the main menu, where Login could become Profile after the user is logged in.

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 description

• Article name and ID
• Language - pre-selected for the description field
• Item name and/or ID - specific to a contest or article template
• For WLM: from ID of monument, then pull category (name of monument) and use as title + something unique, such as username, a counter, and copy that into description
• Feature idea: attach ID of the phone to the photo for two purposes:
  • verifying the photo was taken by that phone later (in case a duplicate appears)
  • further confirming the license choice of "I took this photo"

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 defined by time and location and subject matter
    • 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 their 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

Image curation

• Image curation will be a key feature of New Page Triage and should be activated as close to release of the Advanced Workflow as possible. If it can accompany the Basic Workflow, all the better.

• The workflows documented here can be useful for understanding the possible consequences of all aspects of Photo Upload, and curation in particular.