Wiki Loves Monuments mobile application

Rationale
For the Wiki Loves Monuments 2012 contest, running throughout the month of September (coinciding with European Heritage Days), the addition of mobile photo uploads is under consideration. The Photo Upload project will focus on WLM for its initial release in the form of an app for Android initially and iPhone later (time permitting). WLM is more than a use case for mobile photo uploads; it could be a primary driver of usage.

The reasons to pursue this app as a starting point for mobile uploads are as follows:


 * Mobile uploads are not a current feature of the contest and it would broaden participation, especially among southern countries where reliance on mobile for Internet access is more prevalent
 * Discovery of monuments on mobile is new this year for WLM and has been developed in the form of a WLM layer in the Layar app, which does not connect to the upload process
 * Participation in this contest is expected to grow and is already significant - this provides a boost to engaging users in mobile uploads
 * Marketing by WLM can promote mobile uploads and give this feature significant exposure in a number of countries
 * The well organized and serious nature of the event provides a structured way to test and refine this feature

The number of participating countries in 2012 is 34 definite and 15 possible (so far).

Data and feedback supporting the decision to pursue this app can be seen here.

WLM App development
The WLM App is built on top of PhoneGap and implements the upload process using the Mediawiki API. The app will re-use the Nearby functionality in the Wikipedia apps, and the WLM monuments DB accessed over the WLM API.

Functional requirements
The following list captures high-level requirements. The ToDo list is for development tasks.


 * Choice of nearby monuments or search by city (via country and region)
 * Search by city requires update in DB schema to account for region
 * Nearby monuments in map or list view
 * Map view uses minimum zoom level
 * Optional: distance range or near/far setting - city vs. countryside, if there is time
 * Map view uses clustering (now available in Leaflet)
 * Monuments in any view link to Upload process
 * Optional: monuments in any view can be added to Favorites, if there is time
 * Monument detail view also links to map app for directions, using both address and geo data (if available)
 * Optional: Favorites view collects favorites as thumbnails, opens monument detail view or Upload process
 * Upload view and invoking upload from a monument both require login, or account creation via browser (and then login)
 * Upload view shows completed uploads, or incomplete uploads
 * Incomplete uploads can be selected to finish uploading, or to delete
 * Upload process uses native gallery or camera
 * File submitted by chunked data API - what kind of error recovery is possible, or just start over?
 * After photo selection, monument detail view plus license options
 * Option to delay the upload until later
 * License options come from Brion's API to on-wiki campaign configuration
 * Description step grabs ID template and categories from same API
 * (wireframe screen will be revised to show title and description fields above License)
 * We also will add our own hidden categories for "Mobile upload," "Uploaded with Android WLM App," ideally UA too
 * Title field auto-populated with monument ID and timestamp (not including seconds)
 * Optional description field is available
 * Upload progress in floating window, concludes with "Upload successful" message

Here are the wireframes, in draft form:



The wireframes from the Photo Upload project are useful for seeing the upload process from a general app perspective.

Development issues
The main technical unknowns in this project are:


 * The monument database is accessible through an API on Toolserver, which is slow and may need to be migrated to WMF infrastructure
 * Are countries, which are in the database, equivalent to campaigns?
 * Yes, but other campaign info - license options, ID field template and default categories must come from a new API that accesses the Upload Campaigns configuration info on a Commons Special page (see Related documentation, below)
 * Automatic transfer of metadata, in theory well defined, see below
 * title creation convention using monument name and time/date stamp
 * A view of the user's uploads
 * local (on the device), allowing access to "use" wikitext and ability to see the uploads after the fact
 * There is currently no API for account creation - this is low priority and will be explored further before a decision is made to pursue it
 * possible repercussions in the community need to be explored
 * potential design issues: permissions, rate limiting account creations, account creations by third parties, spam, exposing CAPTCHA (or equivalent)

Initial prototype
Brion Vibber created an initial functional prototype of the application using Cordova 1.7.0rc1. The prototype works both as an iOS and Android app, and can take a photo with the camera or from the photo library and upload it as

The prototype confirms that we have the necessary infrastructure to build the application. Specifically this proves that PhoneGap/Cordova can do login and token checks via the MediaWiki API and then can use Cordova's FileTransfer class to do the upload.

Related documentation

 * Special page for campaign configuration, requires admin or contest admin privileges
 * About the Upload Wizard extension, including URL arguments to pre-populate metadata.
 * Potential issues encountered during development of Upload Wizard, including error cases
 * Discussion of database issues
 * Transfer of the the WLM database and API to Mediawiki servers is in process and the first step is to WMF Labs; a number of  bugs are in process.

Metrics
Data analysis is covered in more detail in the Photo Upload project. Here, the following points are important:


 * the WLM contest runs for one month and we need to collect all of the data that could possibly be useful during that time
 * WLM categories are well defined and should be useful as filters
 * uploads from a mobile source and a particular app or browser should be easily identifiable
 * the measure of quality of uploads could be based on winning photos, following the contest's judging process, as well as whether they are used in articles
 * we need to compare quality of uploads from mobile sources with quality of uploads from non-mobile sources
 * Measure the amount of photo attempts and failures due to poor mobile connections or technical problems

How the contest works
Heritage societies in the participating countries contribute their monument lists, which become the focus of the contest. Users see the campaign for a particular country on wiki, as in this example.

On this screen, it is apparent that some monuments still lack photos. In 2012, users can also look for monuments out in the field using the Layar app. The monument list is accessible through an API that currently resides on Toolserver, and is in the process of being moved to core Mediawiki servers.

Photos are typically taken with cameras, and later uploaded on a computer using the Upload Wizard on Commons. The Upload Wizard is configured for the contest by campaign, which is typically at the country level. Here is an example from Germany that is at the municipality level (Germany may be the only exception to campaigns being at the country level).

It is now possible for the list of monuments on the desktop to link straight to the Upload Wizard by campaign and transfer monument ID and other information automatically, though some aspects of this functionality are still under development. This makes the submission of photos more seamless and reduces the amount of typing the user must do during the upload process. Here is the project page, which includes the list of arguments that can be appended to a URL.

There is a panel of judges per country who then review and pick the winning photos.

Campaigns are defined on Commons using a Special Page called Special:Upload Campaigns. There are many parameters that can be set by the administrators of the contest. You can see those here (requires special privileges).

The following attempts to explain the overall process

Note that a virtuous circle is created by the enhancement of Wikipedia and Commons, which then gets fed back to the heritage societies. There are other benefits as well, such as the fact that the contest opens the door to the broader mission in various parts of the world. A recent example in Italy is described in the GLAM newsletter.