MobileFrontend/Photo upload/Archive

This page collects text that was formerly written ab

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 bugzilla: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):

Overall documentation for 2012:

http://commons.wikimedia.org/wiki/Commons:Wiki_Loves_Monuments_2012/Documentation

The version of Upload Wizard for this project:

https://commons.wikimedia.org/wiki/Commons:Wiki_Loves_Monuments_upload

Monuments will be surfaced through a tool called Layar:

http://owlz.org/?url=http://toolserver.org/~erfgoed/layar/location.html

Toolbox interface:

http://toolserver.org/~erfgoed/toolbox/

Stats:

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

Sample list of monuments - this one from the US and searching for San Francisco:

https://en.wikipedia.org/wiki/National_Register_of_Historic_Places_listings_in_San_Francisco,_California

The API:

http://toolserver.org/~erfgoed/api/api.php

API results:

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

Search in Haarlem, Netherlands for monuments without images:

http://toolserver.org/~erfgoed/api/api.php?action=search&format=html&srmunicipality=Haarlem&props=id%7Cname%7Caddress&srwithoutimage=1

Sample template (National Register of Historic Places in the US):

https://en.wikipedia.org/w/index.php?title=Special%3AWhatLinksHere&target=Template%3ANRHP+row&namespace=0

How it looks with OpenStreetMaps:

http://toolserver.org/~kolossos/wlm/wlm-on-osm.php?zoom=13&lat=52.38003&lon=4.88612

Example of extracting geo-location data from a photo's EXIF data:

https://commons.wikimedia.org/w/index.php?title=File%3ABoard_room_of_the_New_York_times.jpg&action=historysubmit&diff=58720360&oldid=58710362

Maarten's wishlist:

https://commons.wikimedia.org/wiki/User:Multichill#Ideas

An idea to use OpenCV for automatic categorization of images:

https://commons.wikimedia.org/wiki/User:Multichill/Using_OpenCV_to_categorize_files

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.

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 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: bugzilla:33428.

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

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.