I think this makes sense based on the time this has been consuming
from our side.

It would be great to leave the code in a form, that allows 3rd parties
and certain projects to re-enable it if they are finding it useful and
allow for a resurrection later on if necessary. As we build Wikidata
mini games, who knows we might dream up a useful way of improving the
quality of uploads. I can imagine a 'Is this a copyright violation?'
type mini-game, or can you find a picture of this object mini game, so
it would be good to keep these options open.

If nothing else, I feel we can learnt a lot from this. My
understanding is we've never taken a close look at where deletions
come from on certain projects, and whether the quality of photos from
tablets is any better than phones. It would be great to analyse the
existing data we've collected and understand more about how people
used photo uploads and see if there are any useful findings amongst
this experiment.

Jon

On Wed, Aug 27, 2014 at 11:20 PM, Maryana Pinchuk
<mpinchuk@wikimedia.org> wrote:
> tl;dr:
>
> The Mobile Web team has decided to hide the uploads features (upload & add
> to article + upload from left nav) on the mobile site until we have the
> time/resources to rebuild them into a more productive contribution stream.
>
> Background:
>
> Before wikitext or VE editing, the mobile web team built an
> upload-to-Commons pipeline as the first proof-of-concept of mobile
> contribution. When we first launched the two upload features (upload and add
> to article + upload to Commons via the left nav) ~2 years ago, we saw a high
> ratio of these images being deleted (because they were copyright violations,
> test images, selfies, etc.). Since then, we've continued to make incremental
> improvements to address these issues: we added interactive tutorials and
> instruction screens, and also gradually increased the permission levels
> required to see these features (from everyone –> logged-in-only –>
> autoconfirmed only –> 10+ edits).
>
> However, despite all these changes, the ratio of kept to deleted uploads has
> not changed significantly; though the absolute number of uploads per month
> has gone down,[1] 70-80% of these files still get deleted.[2]
>
> This is both a crappy experience for the end-user and a major headache for
> the team – in addition to the pure engineering effort of continuing to
> adjust the parameters of the feature, every incremental change to the
> workflow requires a browser test rewrite, analysis time to figure out if the
> improvements have actually made a difference, and lengthy back-and-forth
> communication with a very unhappy set of Commons admins on Bugzilla. And
> none of the changes to date seemed to have made much of a difference.
>
> In trying to address these issues, we've shifted from focusing on the new
> user persona to the power user... but we're not explicitly revisiting the
> interactions, messaging, or feature set, because we don't have the bandwidth
> to make larger changes. I.e., despite the fact that the feature is now not
> even being shown to brand-new users, we still show a tutorial targeted at
> people who've never contributed before. I think we've reached diminishing
> marginal returns on incremental improvements at this point. If we want
> uploads to succeed, we need to start from scratch: decide who the persona we
> want to target is and then build the set of features that this user is going
> to need.
>
> But rethinking how to instruct newbies (since tutorials don't seem to work)
> or coming up with a whole new workflow aimed at experienced users isn't
> something the team can take on at this point. It requires dedicated product
> and design attention and quite a bit of engineering work, none of which we
> have the resources for.
>
> Since our focus for the year is new active editors and uploads are not part
> of our annual targets, I recommended to the team that we hide the mobile web
> uploading features for now and revisit them either later this year or next
> fiscal year. The team agreed to this at today's planning meeting, and we'll
> be making this change in the coming days.
>
> I know it's not a great feeling when the software we create isn't a rousing
> success, but I think it's really important to be upfront (with ourselves as
> much as with the community) when we see that a feature just isn't doing what
> we want it to do. Lila has been talking a lot lately about how it seems like
> we've been trying to do! all! the things! in WMF engineering – which comes
> at the cost of fragmenting our attention and making it hard to really excel
> at any one of those things. I think she's totally right, and I'd like to see
> our team lead by example and strive for more focus and rigor in terms of
> what we work on and how :)
>
> As always, if you have questions/concerns, feel free to voice them here.
> I'll probably communicate this more broadly sometime early next week.
>
> 1. http://mobile-reportcard.wmflabs.org/graphs/unique-uploaders
> 2. http://mobile-reportcard.wmflabs.org/graphs/deleted-uploads
>
> --
> Maryana Pinchuk
> Product Manager, Wikimedia Foundation
> wikimediafoundation.org
>

> _______________________________________________
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>



--
Jon Robson
* http://jonrobson.me.uk
* https://www.facebook.com/jonrobson
* @rakugojon

_______________________________________________
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l