MobileFrontend/Photo upload

Overview
This page is intended as a general discussion of photo uploads in the context of Wikipedia on mobile devices and related projects such as Wiki Loves Monuments. For specific documents on use cases and functionality, see the following:


 * Use cases
 * Functional requirements
 * Basic Workflow mock-ups
 * Basic Workflow wireframes
 * Advanced Workflow mock-ups
 * Advanced Workflow wireframes

The ability to upload photos is a form of content contribution that is particularly suitable for nearly all mobile devices. Recently, community-led projects such as Wiki Loves Monuments used contribution of photos as a major form of increasing new participation in Wikimedia projects and bringing high-quality content to Wikimedia Commons that can improve the quality of articles in Wikipedia. The software that met the initial needs of that project is called Upload Wizard, and that has become a standard way to contribute photos to Commons.

Upload of photos from mobile devices will follow existing usage patterns, such as sharing content with friends, storing content online, or viewing/contributing content based on location. High-quality photos tend to be large and moving them from a device to another location can involve batch transfers via WiFi. The typical use cases are described below. Some solutions have already been developed, as noted below.

The main goal of this new project is to develop a comprehensive approach to photo uploads across a wide range of mobile devices, using a browser or app, and in two forms: direct upload to Commons (aka Photo Upload Basic) and upload from a Wikipedia article or other front-end (aka Photo Upload Advanced). In general, there will be a design goal of game-ifying the photo upload experience.

One constraint that must be clarified up front is that iOS devices do not offer file access from a web browser. This means that browser-based upload is not easy to enable on iPhone or iPad. Device detection in that case must exclude usage of browser-based upload and reference an app-based approach.

Game-like design
These days the verb to "game-ify" comes up in nearly any context, but in some cases it is justified and can result in great benefits in terms of enhancing user participation and encouraging deeper levels of engagement. Photo uploads are a form of contribution that broadens the funnel in terms of drawing in new users who can directly enhance the completeness and quality of content on Wikipedia and Commons. Social gaming principles could widen the funnel even further and generate new communities of participants. In some cases, it may be possible that game dynamics can cause viral behavior or reactions.

Rankings and ratings are core to gaming. Participation is not limited to contribution of photos. For example, users can rate several photos competing for the spot of being the most representative photo for an article. Once a photo contributor has won this mini-competition, his profile is updated to show how many times he has won, and a leaderboard shows the users who have the most winning contributions. The nice thing about ratings in this context is that it acts as a form of patrolling. Even casual readers can rate photos and then the best ones will get chosen by the participants.

Incorporating this approach with something like Wiki Loves Monuments makes a lot of sense, but it could also work with other types of content and contributions. And of course, this approach applies just as readily to the main site. But on mobile the approach can be tested and refined before being released more generally.

Usage patterns
Three general patterns of usage relating to photos on mobile devices are:


 * sharing with others
 * storing online or on PC
 * location-based viewing

Of course, there is also the basic behavior of taking photos, which is often related to location or social interaction. And if the goal is archival quality documentation, then often a dedicated camera will be used, and not a mobile phone. Because some of the use cases we care about involve Wikipedia articles, we need to account for photos that are not taken with a mobile device but with a more sophisticated camera. In those cases, the user will almost certainly perform the upload through a PC.

For our purposes here, sharing refers to sharing directly from a mobile device. Services such as Picassa and Flickr are clearly designed for sharing, but also for storage, so they will be included in both the first and second patterns.

An additional usage pattern that is specific to Wikipedia is:


 * adding a photo to an article

Within this general pattern, we will consider the specific use case of:


 * seeing an article nearby that needs a photo and contributing one

... and a use case specific to Commons and Wiki Loves Monuments:


 * taking and uploading photos for specific monuments, usually based on a list in a web page

Here are more details:

Sharing
Sharing photos or other content such as videos and URLs is typically a contextual behavior. Meaning, when the user is browsing through photos, he or she gets the idea to share one or more of them.

Therefore, functionality to support this behavior mostly falls outside of the browser or app, and a volunteer developer has already created a plugin-style app that adds Commons to the list of sharing destinations via Android Intents. This is not possible to do on iOS (unless someone can get access to the internals of the photo viewing application developed by Apple).

Here is the app, as well as other community-developed apps. See shareWithCommons on this page. The app installs itself as a Commons option in the Share menu, and adds a category automatically to all photos. Because the photo comes from a mobile device, the presumption that the user is the creator is a reasonable one, and this shortens the licensing interaction.

This approach is valuable in that it addresses sharing at the most useful place, and makes Commons as accessible as Facebook or Flickr or email.

Sharing to Facebook, Flickr, Picassa and other social websites is a form of sharing that is more broadly social, but also more conditional - something about the situation or photo must be more compelling than normal to share in such a visible way straight from a phone. Storing to such sites, which is also by definition social, will be discussed next.

Storing
Photos can be transferred to online destinations or a central PC for the purpose of archiving. In the case of social sites like Facebook and Flickr, the act of storing also achieves the goal of sharing. But there is s difference between posting an album for any friends to explore, and putting a single photo into an event flow so it notifies friends immediately of a current focus, which was mentioned above as a form of sharing.

Storing photos is motivated by factors such as a desire to back-up from a device that could be lost or stolen, a need to free up space on a memory card or internal memory, a way to edit photos more effectively, and a way to distribute or share photos more easily.

Wikimedia Commons as a storage destination is often motivated by other factors: a desire to add to a free, universal repository of images, and as a step toward adding graphics to an article in Wikipedia.

Location-based behavior
Locations are a common impetus for taking pictures, especially in a social context. It is also common in some location-based situations to seek information which can include photos - for example, when looking for a restaurant in a new city or neighborhood. In a travel context, it is common to look online for tourist information and now phones offer a convenient way to do that.

Wikipedia offers travelers excellent information about local landmarks and the Nearby feature currently in the Android and iPhone apps enables that kind of use. Many articles also have geo-location data that can be seen visually, together with articles of landmarks near that one. This has been implemented in the Android app, v1.1.

Some Wikipedia-based apps offer other versions of location-based interaction. For example, Wikitude turns geo-located articles into a form of Augmented Reality, overlaying the article titles on a camera view of one's surroundings.

Adding a photo to an article
The basic use case of photo upload is the one of adding photos to articles, and this in itself can cover a wide range of situations. Articles could be missing photos or not, and be new or mature. For example, a reader could have a useful photo to illustrate a point in a relatively complete article. Or a user could be interested in an obscure topic and want to start an article together with a photo. And possibly the user is in a location where an article about a landmark exists but is missing a photo - adding a photo would be natural and intuitive, if the process to upload a photo is accessible and easy. This last use case will be discussed next.

In general, uploading a photo to an article is a remote possibility for reasons similar to what happens when readers attempt to edit an article - but the reasons are even worse. Most readers are not aware of the ability to edit articles. In terms of adding photos, it is not only difficult to navigate wikitext, but it is not at all clear how photos can be positioned in a layout. And then the most confounding obstacle of all is that photos are not added to Wikipedia directly - they must be added to Commons first, which is not explained anywhere. Adding photos to Commons involves a tedious process of choosing license options, which has been streamlined somewhat by the Upload Wizard, but the average reader has little awareness of licensing issues in general.

Clearly, the use case of adding photos to articles could benefit from a game-like approach. This will be discuss in detail in the next section, which is the use case that will be focused on for the purpose of this project.

Nearby article needing a photo (and geo-location data)
When viewing Wikipedia articles that are nearby, some of them may be lacking photos or may need better photos. Users may notice this incidentally, by simply navigating to nearby articles, or we can present such articles to the user more actively in the mobile site or apps.

A related use case is one of articles that need geo-location data. Contributing a photo with geotags enabled is a handy mechanism for adding geo-location data to an article.

In order to support these use cases, a nice application feature is to surface articles needing photos or geo-location data in some way. For example, when viewing articles nearby, a visible marker of some kind could indicate the articles without any photos. Or in the same nearby view, articles in the relevant location category could be listed for easy access.

In addition, the upload process will be much more intuitive if there is a connected workflow from viewing an article to uploading a photo in a way that the photo remains linked to the article. There is an open bug for implementing this: 33428.

In the next section, a sample workflow will be described in detail.

Wiki Loves Monuments
This is a variation of the above use case. Wiki Loves Monuments is a community-driven project to add photos of notable monuments to Commons. Probably this could be an initial implementation of photo upload, depending on timing.

This is a way to see images from last year:

https://commons.wikimedia.org/wiki/Category:Images_from_Wiki_Loves_Monuments_2011

This project is organized regionally and each city of interest had a page like the following in 2011:

https://fr.wikipedia.org/wiki/Liste_des_monuments_historiques_de_Lille

A simple request from last year's project was to pre-fill aspects of the upload form with some information from the project list. See 33341. This is a related idea to the one mentioned above of linking a photo to an article - both could be achieved by passing some data from an article page to the upload form.

Here is a summary of the current structure of the WIki Loves Monuments project, which in 2012 will encompass 28 countries (many thanks to Maarten Dammers aka Multichill):

http://commons.wikimedia.org/wiki/Commons:Wiki_Loves_Monuments_2012/Documentation
 * Overall documentation for 2012:

https://commons.wikimedia.org/wiki/Commons:Wiki_Loves_Monuments_upload
 * The version of Upload Wizard for this project:

http://owlz.org/?url=http://toolserver.org/~erfgoed/layar/location.html
 * Monuments will be surfaced through a tool called Layar:

http://toolserver.org/~erfgoed/toolbox/
 * Toolbox interface:

https://commons.wikimedia.org/wiki/Commons:Wiki_Loves_Monuments_2011/Monuments_database/Statistics
 * Stats:

https://en.wikipedia.org/wiki/National_Register_of_Historic_Places_listings_in_San_Francisco,_California
 * Sample list of monuments - this one from the US and searching for San Francisco:

http://toolserver.org/~erfgoed/api/api.php
 * The API:

http://toolserver.org/~erfgoed/api/api.php?action=statistics&stcountry=us&format=html&limit=0
 * API results:

http://toolserver.org/~erfgoed/api/api.php?action=search&format=html&srmunicipality=Haarlem&props=id|name|address&srwithoutimage=1
 * Search in Haarlem, Netherlands for monuments without images:

https://en.wikipedia.org/w/index.php?title=Special%3AWhatLinksHere&target=Template%3ANRHP+row&namespace=0
 * Sample template (National Register of Historic Places in the US):

http://toolserver.org/~kolossos/wlm/wlm-on-osm.php?zoom=13&lat=52.38003&lon=4.88612
 * How it looks with OpenStreetMaps:

https://commons.wikimedia.org/w/index.php?title=File%3ABoard_room_of_the_New_York_times.jpg&action=historysubmit&diff=58720360&oldid=58710362
 * Example of extracting geo-location data from a photo's EXIF data:

https://commons.wikimedia.org/wiki/User:Multichill#Ideas
 * Maarten's wishlist:

https://commons.wikimedia.org/wiki/User:Multichill/Using_OpenCV_to_categorize_files
 * An idea to use OpenCV for automatic categorization of images:

Basic workflow
The basic workflow is based on current functionality using Upload Wizard on Commons.

In this workflow, users select a general upload command as the starting point. This launches the login process and opens a mobile version of Commons dedicated to the upload process with a beef explanation. From here, a mobile version of the upload wizard takes the user through the upload, licensing and description steps, and the licensing step is simplified by presenting the case of content created by the user as the default. Also the category can be pre-filled as "Android browser upload" or "Android/iOS app upload."

NOTE: Since upload from a browser on iOS devices is not possible, device detection needs to treat iOS browsers as a special case that is excluded from this workflow. We should also provide a link to our app on the App Store, once our app supports this workflow.

Advanced workflow
The advanced version of photo upload is based on the use case of "Nearby article needing photo or geo-location data." And this should incorporate game dynamics.

In this workflow, a user is browsing an article in the Nearby view that is marked as lacking a photo or geo-location data. An obvious invitation to contribute a photo is highly visible on the article (such as a blank box with a question mark and the text, "Add your photo").

Upon clicking the invitation, the user enters a process similar to the basic workflow, shifting automatically to Commons from Wikipedia with a brief explanation. In addition, an ID of some sort from the article is passed to the upload wizard.

While the photo is curated on Commons, the article ID remains with it and ultimately enables the photo to be placed into the appropriate article. Then the photo becomes part of the article editing process on Wikipedia.

In the use case of adding a photo to add geo-location data, the upload process includes a way of extracting the geo-tag from the photo and preserving it alongside the article ID, so that the geo-location data can be added to the article later.

This workflow includes several initiation points, such as from the Nearby view in an app, and ways of rating or curating photos.

Eventually, we may consider a condensed workflow in which the article (or geo data) is added to the article at the same time as the photo is uploaded to Commons.

A special version of this workflow is based on Wiki Loves Monuments.

Game design
Game dynamics could be categorized in two ways: event-driven and persistent. Scavenger hunts in a given time and place are events; Wiki Loves Monuments is also an event but with a much broader scope in terms of time and place, and a specific subject matter, namely, monuments.

Persistent dynamics could involve competitions that never end or progress to ever-increasing heights of achievement, or social interactions that create endless loops of involvement begetting further involvement. Examples of the former include most traditional types of games, such as casual games and console games, and examples of the latter include social games, role-playing games, and things like Foursquare.

The initial game-like qualities for the Advanced Workflow of Photo Upload will combine both event-driven and persistent dynamics in order to establish some flexibility as future needs come to light. And in particular, the needs of Wiki Loves Monuments can provide some guidance in shaping the initial features.