Mobile/2013 strategy planning



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

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 could potentially work on through the end of Q3/beginning of Q4 in Potential/planned 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. We should also prepare for the situation in which we do reach our target and may want to explore continuing or embarking on 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:
 * 1) A login-related bug is depressing the number of successful web uploaders
 * 2) The Uploads dashboard is still in Beta
 * 3) 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

Potential/planned workflows

 * Nearby

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


 * Pros


 * Substantially increases the efficacy of the lead image upload workflow
 * Creates a persistent work queue for anyone who wants to upload


 * Cons


 * Still has some element of serendipity (user must be in a place around which there are a lot of articles lacking images)
 * Still a one-time thing, and if user exhausts list of articles nearby them, they can’t find more


 * Non-lead image uploads

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


 * Pros


 * Dramatically expands the possible list of articles that can carry an upload CTA


 * Cons


 * Requires high technical overhead: futzing with markup.
 * Image positioning can get strange when they start to pile up, making articles look broken
 * Unknown: how common is it for an article to need images in the non-lead section?

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.

Article image galleries
Allow users to add to existing photo galleries in articles, and/or create new galleries in articles and allow users to add to them


 * Pros


 * Galleries could potentially be infinite, allowing anyone to add their own photo of the Golden Gate Bridge to the GGB article


 * Cons


 * Adding this gallery to desktop may break Wikipedian expectations of their role as content curators and be controversial.
 * May potentially have to be a mobile-only feature, which might confuse desktop and mobile users.
 * May require curation/patrolling – higher community workload
 * A lot of engineering effort to create something like this from scratch

Update outdated images
A call to action for users to add a newer version of images that are out of date.


 * Pros


 * Together with Nearby, can expand the set of articles that users can add images to


 * Cons


 * Requires some method of tagging images as outdated
 * Still has some element of serendipity
 * Unknown: how many images are actually out of date?

Editing
Users are currently editing at a fairly high rate for a beta feature, and #s of unique users per month are climbing. Having the edit button on mobile would:
 * help shephard more experienced users into the mobile space
 * potentially help onboard new users, as E3’s experiments have shown that simple copyediting tasks can entice new users
 * be an easy win for raising editor numbers generally (many mobile editors are brand-new users)


 * 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

Older planning doc

 * Mobile/2013 strategy planning/Archive