Mobile/2013 strategy planning

User test of the upload from left nav feature, iOS

User test of the upload from left nav feature, Android

For previous strategy planning, see: Mobile/2013 strategy planning/Archive

Ask: Please look through the background, current and planned workflows to make sure we're all on the same page with what we're working on in the short-term.

After you've done this, please make sure to add (or +1) at least one new upload or other contribution ideas. These rough ideas will be turned into stories for next quarter during our team planning session in late March; only you can ensure that your brilliant ideas make it into our roadmap!

Q4 planning

Background

The mobile team is working to reach its target of 1,000 unique uploaders per month at the end of this fiscal year. We’ve already built some features and are planning some others – you can see the ones we’ve already created below in Current upload workflows with some early estimates of their impact, as well as ones we'll probably continue working on through the end of Q3/beginning of Q4 in Planned upload workflows.

However, we should still be prepared in case we fall short of our goal with Other upload ideas for getting more users to upload via their mobile device. In the event that we do reach our goal early, we may want to explore new projects like editing and curation/micro-contribution. See Other contributions for those.

Current upload workflows

Lead image upload CTA

A call to action to upload an image to articles that have no images or infoboxes in the lead section.

Uploads dashboard

A call to action to donate an image to Commons via a persistent link in the left nav. Not associated with any articles.

Upload/share via Commons (app)

The ability to take photos and upload them to Commons, and convert existing photos into the appropriate format and share via Commons.

Impact

As of March, we have about 40 unique uploaders a week via web (from the two upload workflows) and 30 via apps, for a projected total of ~300 unique uploaders per month.

In the short term:

A login-related bug is depressing the number of successful web uploaders
The Uploads dashboard is still in Beta
The apps are still very new and haven't been widely publicized yet

After the bug is fixed and Uploads is deployed to full mobile web, the number of web uploaders should go up to at least 75 per week (the total number of unique users who currently started the upload process) from lead article workflow, and potentially 150 per week for uploads dashboard (total number of users who started the upload process X 2 for scale from beta to full mobile web)

This will bring us up to a projected 900 unique uploaders a month. If we get 100 total apps users per month, we might make it to our goal of 1,000 unique uploaders/month!

Showing upload features to logged out users as hooks into login/signup could also increase the impact of these features, netting an additional 500 users per week signing up via the two upload hooks (extrapolating from the watchlist star data – 3,000 users a week signing up from the star, which is on all articles), netting 50-100 extra uploaders per standard conversion rate

Planned upload workflows

Nearby with upload CTA

A call to action to add images to articles nearby that lack them.

Watchlist with upload CTA

Add the upload call to action to the watchlist view to preserve feature parity.

Non-lead image uploads

Give users the ability to add photos to articles that already have images or infoboxes.

Dealing with deleted uploads.

We still need to figure out how we're going to present image deletions to a user.

Campaigns in Commons apps

Campaigns let users add (and view) images to a specific campaign, such as 'Wikimania 2013', or 'Food types at Wikimania 2013', or 'Wiki takes San Francisco Jun 2013' or anything that you can think of. Think of these as more structured hashtags on Instagram.

Impact

We don't currently have data on the Nearby upload process, but media attention around the early alpha prototype shows that it will may pique new user curiosity/engagement.

Widening the heuristic for in-article uploads feature will definitely have an impact. Currently, based on a random sample of 50 articles on English Wikipedia, the lead image upload button only shows up on about 18% of articles. We could explore widening the heuristic to include:

Very short stubs, which current don't register as needing images (about 10% of enwiki articles)
Articles with infoboxes but no images in lead section (about 48% of enwiki articles)
Articles that already have images (about 24% of articles)

Based on this data, it probably makes sense to start by figuring out section-level uploading.

Other upload ideas

Wiktionary Word prononciation uploading

A gamified small app that lets you record pronunciations and upload them to commons, and automatically inserts them into the appropriate Wiktionary article at whatever language. See recent thread on wikitech-l about this.

Upload a similar photo

On photo pages themselves we might want to encourage photo uploads from there. For instance if I am looking at a photo of the white house imagine a button "Upload your photo of the White House"

Suggest a photo for this page

Currently we only show the add photo call to action on pages that need photos. There is an alternative for photos which already have one! When they already have one, show the call to action (maybe smaller or more hidden) but with the text "Suggest a photo for this page". The workflow is exactly the same except one difference - the photo is tagged with the categories of the current article and the name of the current article and a link is added to the article talk page 'Photo suggestion: Link to photo'. The idea being that editors can take into account these suggestions.

Article image galleries

Allow users to add to existing photo galleries in articles, and/or create new (potentially mobile-only) galleries in articles and allow users to add infinitely to them.

Wireframe of a mobile gallery idea

Update outdated images

A call to action for users to add a newer version of images that are out of date. Requires also allowing users to mark images as outdated.

Wireframe for a potential mobile flagging/replacing outdated images workflow

Associate images with articles

Let users associate an image with an article. Give users a search bar to find an article related to the image they just uploaded, and allow them to either add the image to the article (in the middle, to the mobile gallery) or add it to a Commons gallery associated with the article subject. Or can find out the associated commons category for a page (parse out the commonscat template) and add to that. Also a good idea to do this from the app, in the post upload screen.

Wireframe of a mobile upload workflow for associating uploads with articles or Commons galleries

Apps sharing, geotagging, referencing

Register iOS custom URL scheme (https://developer.apple.com/library/ios/#documentation/iphone/conceptual/iphoneosprogrammingguide/AdvancedAppTricks/AdvancedAppTricks.html) and Android intent filter handling (https://developer.android.com/training/sharing/receive.html) so that users can:

Directly from their camera app or gallery, use the share feature and choose the Commons app to ingest the image.
- If the image is geotagged, provide a button to look for nearby articles.
- If GPS or triangulation is on, provide button to look for nearby articles based upon GPS/triangulation if the image datetime stamp on the image is really fresh.
- Have a search button for users to look for articles or to create stubs, irrespective of image geotag or GPS/triangulation sensor disposition.
Directly from browsing or other apps with URLs, use the native share feature and choose the Commons app to add the hyperlink as a reference.
- If the URL isn't already found as a reference somewhere, prompt the user to look for the article to which to add it or the stub to create.
- If the URL is already found as a reference, show the user places it is already present and give the user the ability to look for other articles or to create a stub.
- Give the user the option to add it to scratch space for later workflow from the full web UI (e.g., with a localized GUID in local storage for later transmission to the server, or even with a server-backed GUID-linked persistence-backed object).
The camera and gallery stuff would probably be usable enough for the Wikipedia app, too, but the URL piece is probably only suitable for the Commons app expert. But maybe one way to expose the URL piece in the main Wikipedia app is to have it be an 'Advanced' feature, where 'Advanced' is unchecked by default.
Note that this broadens the reach to users directly, even if the developer didn't take advantage of MediaWiki API hooks to connect to core Wikimedia infrastructure.

Wikipedia and Wiktionary search widgets

I've always wanted a search widget that lets me get Wikipedia and Wiktionary results from my home screen.

Android search bakes in Wikipedia search as an option, at least on a stock Nexus 7 with Jellybean, so some devices don't need the Wikipedia search piece. But Wikitionary search is still interesting in any case. And providing this option independent of Google's search feature may be something users want even on Android, perhaps if they pulled out Wikipedia search at some point earlier in their Jellybean device, or simply don't use the Google search widget.

Article of the day widget

I've always wanted a widget to display an article of the day on my home screen. This should not be permitted to artificially inflate page hit counts. A clickthrough or scrollthrough action on the widget would be a fair indicator of a legitimate clickthrough.

A geolocation-based article could also be presented. There could be default behavior for being in geolocation versus article of the day mode, with some tuning.

A user setting to choose the level of polling (e.g., once every 5 minutes, once every 90 minutes, default = never) would be advisable, and could reduce battery drain plus user annoyance.

(Note: All this is doable very nicely in a non-battery-draining way in Android)

Notification area

Add a background service or, maybe just an activated task that runs when only Commons or the main Wikipedia apps are running, that polls GPS/triangulation periodically, and pops a message in the notification area or in the case of the Commons/Wikipedia app the foreground (plus maybe notification area) if there are nearby articles flagged for needing an image or perhaps even for further editorial content. This should not be a GPS/triangulation, bandwidth, or battery drain. This may be achievable as a JavaScript-based GPS/triangulation hook, too. In both cases, the server-side query has to be executed, although optimization would be possible by doing a radius or square search for nearby geos and watch where user is traveling and keeping that in a small in-memory structure, at least provided geo velocity isn't on a high speed vehicle. A user setting to choose the level of polling (e.g., once every 5 minutes, once every 90 minutes, default = never) would be advisable, and could reduce battery drain plus user annoyance.

(This is known as GeoFencing, and is doable with minimal battery draining on Android)

wikipedia:// and wcommons:// protocol handlers

The MediaWiki API is the cleanest way to gain integration from other apps, but native support of wikipedia:// or wcommons:// protocol handlers that have a clean RESTful style and are immune to local device injection attacks may be something other app developers would like. The orchestration that's done in the native apps or the page level server side code execution could handle the heavy lifting of interacting with the MediaWiki API, but the wikipedia:// or wcommons:// protocol handlers could be a lightweight and even simpler way to abstract away details. Even in the least-effort case, wikipedia:// or wcommons:// protocol handlers could have near parity with the MediaWiki API, forming a facade, but not a full blown proxy. This is another way to raise awareness about integration possibilities, although emphasis on the MediaWiki API may be a better way of letting app developers do what they want directly.

(On android at least, content-uris (like those mentioned here) are supposed to be synchronous, and hence not suitable for API style work)

Link to Flickr

Lots of users might want to import flickr photos to Commons. Would be great to make this easier by providing ability to load images from Flickr and provide easy way to batch upload selected ones to Commons.

Your ideas here

Your ideas for upload-related features go here!

Other contributions

Editing

Productizing the editing feature. Still needed:

work out all the bugs (e.g., periodically causes sections to be blanked, anons are editing despite feature being theoretically gated to logged in only)
create a MVP midway point for the edit form – slightly better than the current interface, but not yet VisualEditor quality
remove the cruft from the bottom of the form
log global contributions, not just enwiki

Backlog Clearing Micro-apps

Commons / Wikis have plenty of 'backlogs' that need clearing. Examples include links to disambiguation pages that need fixing, Images needing categorization, Orphaned pages needing links into them, images needing cropping, etc. These are incredibly easy to gamify, and can serve as a gateway 'hook' into having people contribute more. A lot of these can also be done without logging in!

Adding categories

Give users the ability to add categories to their or others' uploads.

Wireframe of a workflow for adding categories to mobile uploads

Upvote/downvote images

Give users the ability to upvote or downvote images uploaded via mobile. Images that get downvoted too low may be automatically flagged for deletion, and images that are upvoted may appear with a special badge/star on mobile articles and in the user's Uploads view.

Wireframe of a potential mobile image curation (upvote/downvote) workflow

Mobile GettingStarted

Use the concept of onboarding that E3 is experimenting with on desktop and translate it to mobile web – give newly registered users a small suggested task or a quick tutorial of important logged-in features (e.g., uploading, watchlist)

The GettingStarted page on desktop English Wikipedia, which appears immediately after signup

Watchlist reverting

Allow users to revert vandalism via the watchlist. Will need some kind of warning component, whether that's template talk page messages or Echo notifications.

More login/signup hooks

Display more features (e.g., edit button) to logged out users to get them to login/sign up.

Talk page commenting

Show users a link to article talk pages and allow them to add new sections.

Option to only load search bar instead of front page

Make a user setting to automatically load just the search bar instead of the whole front page when the app is brought up. This would be for users who mostly only use the search function, since search lags waiting for front page to load when the user first opens app.

Your ideas here

If you have other ideas for features not strictly related to uploads that we should work on in the next quarter, feel free to add them here!

Older planning doc

Mobile/2013 strategy planning/Archive