Re: [WikimediaMobile] [Apps] New Android production release

[Jon Katz]

A belated congratulations to the Android team for this release!
I've started editing image captions and it's excellent and, based on some
preliminary numbers, it looks like our users are happy too!
-J

On Wed, Aug 7, 2019 at 2:38 PM Dmitry Brant  wrote:

> Hey everyone,
>
> We're excited to release our latest update to the Wikipedia Android app
> , now
> available on the Google Play store. Aside from numerous minor enhancements
> and bug fixes, the biggest highlight from this update is:
>
> == *Suggested edits, the continuation ==*
> Earlier this year we released the "Suggested edits" screen (accessible
> from the left navigation menu in the Feed screen, when you're logged in)
> which offers you a stream of suggested contributions. Initially these
> contributions were limited to adding and translating Wikidata descriptions
> for articles that were missing a description.
>
> We have now expanded these suggested contributions to include adding and
> translating structured image captions on Commons!  The Suggested Edits
> screen now presents you with images that are missing a structured caption,
> or if you have more than one language configured in the app, it shows you
> images that are missing translations of the caption into the other
> language(s) that you have selected.
>
> You may also add or translate the captions of images directly while
> browsing articles. Tap on any image to go to the full-screen gallery, and
> you should see options to add, edit, or translate the caption.
>
> Check it out, and we'd love to hear your feedback.
> Cheers,
>
> --
> Dmitry Brant
> Senior Software Engineer (Android)
> Wikimedia Foundation
> https://www.mediawiki.org/wiki/Wikimedia_mobile_engineering
>
> --
> You received this message because you are subscribed to the Google Groups
> "android" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to android+unsubscr...@wikimedia.org.
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Wikipedia app v6.3 published to app store

[Jon Katz]

Congratulations to the iOS team!  These are great additions to the iOS
contributor experience.
-J

On Thu, Jul 11, 2019 at 1:48 PM Joshua Minor  wrote:

> Hello mobile Wikimedians,
>
> The Wikimedia iOS app team is excited to announce our next major update is
> now available on the app store:
> https://itunes.apple.com/WebObjects/MZStore.woa/wa/viewSoftware?id=324715238=8
>
> v6.3 is chock-a-block with fixes and features, including:
>
>- Been having trouble syncing reading lists or downloading reading
>lists to new devices? We fixed a ton of sync problems!
>- Easy support for adding media from Wikimedia Commons in editing
>mode. Press the media button and easily an images to add with a tap.
>- Easy wiki link insertion and updating tool.
>- Fix issues with currently reading article not reopening after app
>background. Now when you return to the article it will still be there!
>- Join the conversation with support for User talk built in. Go to
>Settings and log in to see your user talk  in a mobile friendly
>presentation.
>- A fresh new sticker pack from the Foundation's Communications team
>and Giphy.
>
> Thanks as always to our volunteer translators, coders and testers. If
> you'd like to sign up to help beta test future versions, you can now sign
> up directly here:
> https://testflight.apple.com/join/Z0AU0KXC
>
>
> Cheers,
> Josh Minor
> PM, Wikipedia for iOS
> ___
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Fwd: [Offline-l] Wikimed Mini release

[Jon Katz]

apparently this didn't reach mobile-l

-- Forwarded message --
From: Stephane Coillet-Matillon 
Date: Thu, Aug 24, 2017 at 12:38 AM
Subject: [Offline-l] Wikimed Mini release
To: mobile-l , Using Wikimedia projects and
MediaWiki offline 


[Cross-post]

A quick note to announce that Kiwix released this morning a new version of
the Wikimed App called Wikimed Mini [1]. It basically complements the
earlier app in that it is 90% smaller and should therefore make it easier
to download and store by users who need it most (50% of installs for the
English version happen on the Indian subcontinent; for the French one, 80%
are in Africa).


But apart from this PSA I wanted to share the thinking that went behind the
design of this particular app, as I’ve been told it could be of interest to
this list:

There basically were three reasons for this "mini" version:

1. When connectivity is an issue, size does matter. If you look at the 20+
main offline medical apps out there, you'll see that they all range in the
25-40Mb (the largest being 120Mb). Several of them have 1M+ downloads, and
even if I am no physician I'd say their content is rather minimal and that
WP content is far better: yet people download the other, smaller apps
rather than our gigantic, all-encompassing 1.2 Gb one;

2. You may have heard that thing about 60% of mobile readers not going past
the Lead section [2]. We did too, and took the drastic step of removing
everything below that - basically keeping only the lead part and infobox.
That saved us about 60%;

3. Then we looked at what was left and figured that infobox illustrations
weren't that helpful: either because they look good but are not very
informative, or because if they are in fact informative offline limitations
make it impossible to see more than a thumbnail. Don't get me wrong: the
ability to see high-res images comes high on the list of requests, but a
choice was to be made and that one was a low-hanging fruit. So we removed
the illustations as well, and now we're left with a 90% smaller app.

In spite of its size, the current Wikimed is rated higher (4.7) and kept
longer (75% retention at D30) that most apps (4.2/20%, respectively on
average): we’ll keep you posted on how the new app fares in comparison to
that.


Cheers,
Stephane



[1]  https://play.google.com/store/apps/details?id=org.
kiwix.kiwixcustomwikimedmini
[2] https://meta.wikimedia.org/wiki/Research:Which_parts_
of_an_article_do_readers_read





___
Offline-l mailing list
offlin...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/offline-l


signature.asc
Description: PGP signature
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Wikipedia app v5.5.0 released

[Jon Katz]

Congratulations, iOS team!!

On Tue, Jun 20, 2017 at 3:28 PM, Joshua Minor  wrote:

> Hello mobile Wikimedians,
>
> The iOS team is excited to announce that v5.5.0 of the Wikipedia app for
> iOS is now available in the app store:
> https://itunes.apple.com/us/app/wikipedia/id324715238?mt=8
>
> This is a MAJOR update with tons of bug fixes and improvements. Highlights
> include:
>
>- New Places tab lets you find Wikipedia articles about places near
>you, or across the globe. Use maps to find the most interesting articles
>next door, or anywhere your curiosity takes you.
>- Quick search box on the Explore screen lets you easily access the
>search menu to find the information you need, now.
>- Streamlined "In the News" design, makes it easier to learn more
>about what’s happening around the world.
>- Updated Explore design makes discovering new content even easier.
>Added "infinite" scroll so you can catch up on what you missed just by
>scrolling down.
>- Clear app caches from the Settings menu, to reclaim storage the
>Wikipedia app takes on your device.
>- Overall performance improvements mean faster loading and smoother
>scrolling
>
> As usual I'd like to thank our beta volunteers, translatewiki localizers
> and all the folks that participated in user feedback rounds. I also want to
> particularly thank volunteer contributor NHarateh for her several patches
> on this version!
>
> Thanks,
> Josh Minor
> PM, Wikipedia for iOS
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Prague Pre-Hackathon - registration and travel scholarships open

[Jon Katz]

Hi Pine,
That's a great question and one we've thought about a lot on the app
teams.  It would obviously increase our image contributions a great deal if
we connected the ease of uploading of the commons app with the user base of
the Wikipedia app.  However, given the quality and copyright issues that
arose when we previously made it easier to upload images on the mobile [1],
we want to be very careful about any future efforts and make sure we've
ensured that issues around moderation are taken care of.

In a recent consultation around mobile contributions,
https://www.mediawiki.org/wiki/Reading/Readers_contributions_via_Android,
concerns around moderation were echoed, but uploading nearby images was
still one of the most popular ideas proposed. There is clearly an
opportunity here if we can figure out how to mitigate the moderation issues.

Regardless, given the upcoming structured data on commons
 project, we're
thinking that we want to delay any new asks of the Commons community until
the repercussions of the project are well understood.

Best,

J



[1]

Compiled by: https://commons.wikimedia.org/wiki/User:LX

Commons:Village pump/Archive/2013/04#Mobile Web Uploads turned off in stable


Commons:Village pump/Archive/2013/04#Missing author/source parameters on
mobile uploads: fix coming


Commons:Village pump/Proposals/Archive/2016/08#Rfc: Should we request a
configuration change to shut down cross-wiki uploads?


Commons:Mobile access/Mobile upload needing check#Background


Category:MobileUpload-related deletion requests



On Thu, Mar 2, 2017 at 9:12 AM, Pine W  wrote:

> Hi Josephine,
>
> I'm glad to see that work is continuing on the Commons app. Just
> wondering, is there a chance of creating some kind of link between the
> Commons app and the Wikipedia app, or maybe even merging them at some point?
>
> Thanks,
>
> Pine
>
>
> On Thu, Mar 2, 2017 at 6:30 AM, Josephine Lim 
> wrote:
>
>> Hi all,
>>
>> Wikimedia Czech Republic and I are collaborating to organize a
>> pre-hackathon
>> 
>> in Prague that runs from 12-14 May 2017, a week before the hackathon in
>> Vienna. There are a few scholarships available that will cover the return
>> trip to Prague/Vienna, and/or accommodation in Prague during the
>> pre-hackathon.
>>
>> The topic of the pre-hackathon will be the improvement of the Wikimedia
>> Commons Android app ,
>> with focus on the "Nearby places that need pictures" feature. Further
>> details are currently still being discussed here
>> .
>>
>> If you are interested, please register
>> 
>> as soon as possible and indicate if you would like to apply for a
>> scholarship in the application form. For any enquiries, feel free to send
>> me or Vojtech (CC'ed) an email, or post on our GitHub or wiki discussion
>> page.
>>
>>
>> Cheers!
>>
>> --
>> Regards,
>> Josephine
>>
>> ___
>> Mobile-l mailing list
>> Mobile-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>>
>>
>
> ___
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Readership metrics for the timespan until February 5, 2017

[Jon Katz]

On Wed, Feb 15, 2017 at 9:54 AM, Jon Katz <jk...@wikimedia.org> wrote:

> early results suggest the number for both apps is much higher than the web.


Hey Pine,
I need to walk this portion of my email back.  I'm not saying the opposite
is true, just that it is just too early to say this with confidence.
Thanks to Tilman for rightly pointing this out ;).  I apologize for any
confusion caused.
Thanks,
J
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Readership metrics for the timespan until February 5, 2017

[Jon Katz]

Hi Pine,
I believe I answer your questions inline.

On Wednesday, February 15, 2017, Pine W <wiki.p...@gmail.com> wrote:

> Jon, thanks for the explanation. Comparisons between mobile web and the
> mobile app retention rates would indeed be helpful.
>
> Does Wikipedia Zero work only with the apps, or do users also get free
> access to Wikipedia mobile web?
>

Wikipedia Zero works on *both* apps and mobile web.


> As an editor, I previously found that the Android app was missing many
> features that I wanted, and I found that mobile web editing was difficult
> to accomplish. In the upcoming annual plan for the mobile experience, both
> for apps and mobile web, will there be a focus on improving usability for
> mobile contributors?
>

So glad you asked as its something I am personally excited about!  A
consultation
on one angle
<https://www.mediawiki.org/wiki/Reading/Readers_contributions_via_Android>
on this subject is wrapping up on this topic and I will be summarizing the
results shortly--feel free to chime in as it hasn't ended yet. Our Android
app is also exploring a specific approach- editing wikidata descriptions in
a mobile-optimized way
<https://www.wikidata.org/wiki/Wikidata:Requests_for_comment/Editing_descriptions_from_Wikipedia_Android_app>.
As far as annual plan, we are still working on a draft for community review
and I don't want to make any statements that might be proven wrong, but
it's definitely under consideration.


> Thanks,
>
> Pine
>
>
> On Wed, Feb 15, 2017 at 9:54 AM, Jon Katz <jk...@wikimedia.org
> <javascript:_e(%7B%7D,'cvml','jk...@wikimedia.org');>> wrote:
>
>> Hi Pine,
>> I think for those who are not used to working with it, the day 7
>> retention rate can look low, but it's important to remember that this day 7
>> retention metric is not the number of users who continue to use the app
>> after 7 days.  It is the number of people who actually visit on the 7th
>> (not the 6th, not the 8th, not the 100th) day after using it for the first
>> time.  It is a standard app metric and we fit well within the benchmark
>> here.  We are working on a similar metric for the web, and early results
>> suggest the number for both apps is much higher than the web.
>>
>> -J
>>
>>
>> On Tue, Feb 14, 2017 at 10:54 PM, Tilman Bayer <tba...@wikimedia.org
>> <javascript:_e(%7B%7D,'cvml','tba...@wikimedia.org');>> wrote:
>>
>>> Hi Pine,
>>>
>>> out of curiosity, what is the "rather low" assessment based on? Does
>>> this refer to an industry standard (links welcome), or is it more a
>>> subjective, personal impression?
>>>
>>> In any case, thanks for reading the report and sharing your thoughts -
>>> glad to see that it stimulates metrics-based thinking.
>>>
>>> On Tue, Feb 14, 2017 at 8:33 PM, Pine W <wiki.p...@gmail.com
>>> <javascript:_e(%7B%7D,'cvml','wiki.p...@gmail.com');>> wrote:
>>>
>>>> Thanks Zareen. I'm particularly interested in the mobile app retention
>>>> percentages, which seem rather low. I wonder if it would make more sense to
>>>> take all the money and employee hours that are currently being invested in
>>>> mobile apps, and redirect those resources to mobile web.
>>>>
>>>> Pine
>>>>
>>>>
>>>> On Tue, Feb 14, 2017 at 4:45 PM, Zareen Farooqui <zare...@gmail.com
>>>> <javascript:_e(%7B%7D,'cvml','zare...@gmail.com');>> wrote:
>>>>
>>>>> Link to PDF of report in Commons
>>>>> <https://commons.wikimedia.org/wiki/File:Wikimedia_Readership_metrics_for_the_timespan_until_February_5,_2017.pdf>
>>>>>
>>>>> Hi all,
>>>>>
>>>>> Here is the usual look
>>>>> <https://www.mediawiki.org/wiki/Reading/Readership_metrics_reports>
>>>>> at our most important readership metrics. This time we see an overall rise
>>>>> in pageviews following the seasonal winter slump, examine the recent
>>>>> year-over-year growth in pageviews more closely, and introduce a new day-7
>>>>> retention metric for the Wikipedia iOS app.
>>>>>
>>>>> As laid out earlier
>>>>> <https://lists.wikimedia.org/pipermail/mobile-l/2015-September/009773.html>,
>>>>> the main purpose is to raise awareness about how these are developing, 
>>>>> call
>>>>> out the impact of any unusual events, and facilitate thinking about core
>>>>> metrics in general. As always; feedback and discu

Re: [WikimediaMobile] New “On this day” service and location data in summaries

[Jon Katz]

Congratulations to those involved!  This will enable important (and asked
for) features for our users, and another step in the right direction
technically as we leverage more services across multiple platforms and the
broader ecosystem.

-J

On Wed, Feb 15, 2017 at 8:15 AM, Derk-Jan Hartman <
d.j.hartman+wmf...@gmail.com> wrote:

> > For more information, check out the docs:
> > https://en.wikipedia.org/api/rest_v1/#!/Feed/aggregatedFeed_0
>
> The docs could use some spelling control :)
>
> DJ
>
>
> On Tue, Feb 14, 2017 at 5:00 PM, Corey Floyd  wrote:
>
>> A couple updates for the Mobile Content Service and RESTBase:
>>
>> A new MCS service was deployed yesterday that returns events, holidays,
>> birth and deaths. This service is powered using Wikipedia contributed by
>> our volunteers. It currently works for EN, DE, FR, SV (with rollout to more
>> languages being planned).
>>
>> For example, to see today’s births:
>> https://en.wikipedia.org/api/rest_v1/feed/onthisday/births/02/14
>> (Source: https://en.wikipedia.org/wiki/February_14)
>>
>> Even better, it returns the curated list selected anniversaries:
>> https://en.wikipedia.org/api/rest_v1/feed/onthisday/selected/02/14
>> (Source: https://en.wikipedia.org/wiki/Wikipedia:Selected_anniversari
>> es/February_14)
>>
>> For more information, check out the docs:
>> https://en.wikipedia.org/api/rest_v1/#!/Feed/aggregatedFeed_0
>>
>> Thanks to Monte and Bernd for working on this and creating a very useful
>> endpoint!
>>
>>
>> Another minor, but useful improvement made earlier this month was the
>> inclusion latitude and longitude in RESTBase summaries by Petr:
>> https://en.wikipedia.org/api/rest_v1/page/summary/atlanta
>>
>>
>> Special thanks to Petr, Marko and the rest of the Services team for all
>> their help and consultation. They continue to be great partners for the
>> Reading team and their contributions have been key to so much of our work
>> over the past year.
>>
>>
>>
>>
>> --
>> Corey Floyd
>> Apps Engineering Manager
>> Wikimedia Foundation
>> cfl...@wikimedia.org
>>
>> ___
>> Mobile-l mailing list
>> Mobile-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>>
>>
>
> ___
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Readership metrics for the timespan until February 5, 2017

[Jon Katz]

Hi Pine,
I think for those who are not used to working with it, the day 7 retention
rate can look low, but it's important to remember that this day 7 retention
metric is not the number of users who continue to use the app after 7
days.  It is the number of people who actually visit on the 7th (not the
6th, not the 8th, not the 100th) day after using it for the first time.  It
is a standard app metric and we fit well within the benchmark here.  We are
working on a similar metric for the web, and early results suggest the
number for both apps is much higher than the web.

-J


On Tue, Feb 14, 2017 at 10:54 PM, Tilman Bayer  wrote:

> Hi Pine,
>
> out of curiosity, what is the "rather low" assessment based on? Does this
> refer to an industry standard (links welcome), or is it more a subjective,
> personal impression?
>
> In any case, thanks for reading the report and sharing your thoughts -
> glad to see that it stimulates metrics-based thinking.
>
> On Tue, Feb 14, 2017 at 8:33 PM, Pine W  wrote:
>
>> Thanks Zareen. I'm particularly interested in the mobile app retention
>> percentages, which seem rather low. I wonder if it would make more sense to
>> take all the money and employee hours that are currently being invested in
>> mobile apps, and redirect those resources to mobile web.
>>
>> Pine
>>
>>
>> On Tue, Feb 14, 2017 at 4:45 PM, Zareen Farooqui 
>> wrote:
>>
>>> Link to PDF of report in Commons
>>> 
>>>
>>> Hi all,
>>>
>>> Here is the usual look
>>>  at
>>> our most important readership metrics. This time we see an overall rise in
>>> pageviews following the seasonal winter slump, examine the recent
>>> year-over-year growth in pageviews more closely, and introduce a new day-7
>>> retention metric for the Wikipedia iOS app.
>>>
>>> As laid out earlier
>>> ,
>>> the main purpose is to raise awareness about how these are developing, call
>>> out the impact of any unusual events, and facilitate thinking about core
>>> metrics in general. As always; feedback and discussion welcome.
>>> Week-over-week and month-over-month changes are being recorded on the
>>> Product page 
>>> at MediaWiki.org. This edition of the report covers a timespan of five
>>> weeks.
>>>
>>> You can also find lots of other traffic and usage data in the quarterly
>>> metrics presentation
>>> 
>>> for Q2 2016-2017 (October - December) that was just published by the WMF
>>> Reading team.
>>>
>>>
>>> All numbers below are averages for January 2 - February 5, 2017 unless
>>> otherwise noted.
>>> Pageviews
>>>
>>> Total: 582 million/day (+10.14% from the previous report)
>>>
>>>
>>> Context (April 2015-February 2017):
>>>
>>>
>>> See also the Vital Signs dashboard
>>> 
>>>
>>> After the seasonal winter slump, we see a rise in desktop pageviews, as
>>> expected. Mobile pageviews continue to remain at higher levels than before
>>> christmas. The previously mentioned iOS app’s pageview increase is still
>>> under investigation, and may turn out to be an anomaly
>>>  inflating mobile pageviews
>>> by roughly 5 million views per day.
>>>
>>> This chart looks at long-term traffic trends from May 2013 - January
>>> 2017. This shows that over this timespan, the annual change in overall
>>> pageviews was -2%, desktop has been down 15%, and mobile (web + apps) has
>>> been trending upwards at a rate of 23% per year. However, the past few
>>> months have seen total pageviews increasing year-over-year (chart further
>>> below).
>>>
>>> To facilitate our understanding of which traffic movements are seasonal
>>> and which may indicate lasting changes, here is a chart overlaying the
>>> total pageview numbers back to May 2013 (the earliest time for which we
>>> have data according to the current pageview definition):
>>>
>>>
>>> Total pageviews have continued rising and are now higher than before the
>>> winter holidays. The blue line shows that the increase in overall pageviews
>>> year-over-year remains (January 2017 is up 5% from January 2016). It is
>>> possible that a smaller part of this is due to unidentified bot traffic
>>> (e.g. we just updated  the
>>> pageview definition to exclude a recently discovered bot that had been
>>> causing up to 0.9% of total pageviews). But overall it is starting to look
>>> like a small but sustained rise in real human pageviews.
>>>
>>> Here we see that the changed 

Re: [WikimediaMobile] [Apps] New Android production release

[Jon Katz]

Congratulations, team! It looks great.

On Fri, Sep 30, 2016 at 1:26 PM, Dmitry Brant  wrote:

> Hi everyone,
>
> We're excited to bring you an updated version of the Wikipedia Android app
> ,
> rolling out now to the Google Play Store! [1]
>
> This version contains the following updates:
> - Access your favorite features more easily with bottom navigation:
> quickly jump between the Explore feed, your reading lists, your
> recently-viewed articles, and pages nearby you.
> - When reading an article, the bottom toolbar now provides access to the
> most popular actions (save to reading list, share, change language, find in
> page, and table of contents).
> - Reading lists and their contents are now searchable.
> - A number of minor bug and crash fixes.
>
> Want to help make the app even better? Read our getting-started
> 
> guide, and start contributing!
>
> [1] For devices without Google Play services, you may download
> 
> the app directly.
>
>
> Cheers,
>
> --
> Dmitry Brant
> Senior Software Engineer / Product Owner (Android)
> Wikimedia Foundation
> https://www.mediawiki.org/wiki/Wikimedia_mobile_engineering
>
>
> ___
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Wikipedia app for iOS v5.1.0 released

[Jon Katz]

Congrats, iOS and the volunteer contributors!  Find in page is huge.
-J

On Tue, Aug 30, 2016 at 5:10 PM, Joshua Minor  wrote:

> Hello,
>
> This morning the WMF's iOS app team released version 5.1.0 to the app
> store [1]
>
> This version includes:
>  *- Search within articles!!!*
>  - New designs to make reading and exploring on iPads even better
>  - Faster browsing for users with large histories and saved page libraries
>  - Nearby recommendations that are more relevant to your current location
>  - Ability for 3rd party apps to open specific articles or searches via URL
>  - Lots of other small fixes!
>
> Special thanks to volunteer contributors kevintaniguchi and jberkel for
> their excellent additions! And as always thanks to our beta testers for
> your bug reports and feedback.
>
> [1] - https://itunes.apple.com/th/app/wikipedia/id324715238?mt=8
>
> Thanks,
> Josh Minor
> PM, Wikipedia for iOS
>
>
>
> ___
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] [Wikimedia-l] Fwd: "Among mobile sites, Wikipedia reigns in terms of popularity"

[Jon Katz]

Hi,
For those of you following who I haven't worked with before, I am the lead
product manager for the reading team.

I think James is right that the content is a primary barrier and its an
issue we are exploring across both reading and editing.  For what its
worth, this applies not just to the web but to all non-desktop usage,
including apps and 3rd party developers. I believe our 3rd meeting on the
topic is tomorrow morning and Moushira just posted this invitation to
participate more broadly on wiki:
https://www.mediawiki.org/wiki/Reading/Mobile_Friendly_Content.

Whether we end up getting rid of the mobile site or follow another path
towards unity is an open question.

Another big barrier to having a single site and one we have to address
regardless, is how we add advanced tools to mobile without crushing the
average user.  Over the years the desktop site has accumulated many useful
features/tools and this is reflected in the various rich options on the
desktop site. Mobile screen real estate, however, is much more limited and
the affordances are quite different.  So far, we have focused on a simple
experience because we know we can't mush the entire left-hand navigation
field into the mobile menu or provide the same list of 40+ settings that
are on desktop.  This has provided us with a remarkable experiment in
reading that at least anecdotally suggests most readers prefer a simpler
experience.

However, it does not yet work well for editors and certainly not for more
advanced contributions. So, we need to figure out how we can maintain the
pathway from reader --> contributor on mobile without generating a user
experience nightmare.  One of our big challenges in creating a unified
experience is figuring out how we move someone from a basic reading view to
a first-time editor view, to a power-user-genius view in a way that entices
a potential contributor and optimizes the experience for everyone else.
There are multiple options on the table here and I think it's going to be a
long conversation ;)

Thanks,

J

On Wed, May 11, 2016 at 2:25 PM, James Forrester 
wrote:

> On 11 May 2016 at 14:20, Michael Peel  wrote:
>
>> I'm hoping that having a responsive skin for the webpages isn't too far
>> off, though?
>>
>
> Reading can answer that better than I; however, making the skin itself ​is
> only part of the issue – you also would want to scrap m.wikimedia.org
> *etc. *​Right now, the mobile sites have to make massive changes to the
> content to make it fit on​ a mobile screen (and even then can't fix some
> things, like tables). Giving mobile users a responsive skin whilst the
> contents weren't appropriate wouldn't make anyone happy. Until the contents
> of at least most the millions of pages of Wikimedia wikis' projects are
> mobile-safe, we can't reasonably get rid of the mobile "site".
>
> J.
> --
> James D. Forrester
> Lead Product Manager, Editing
> Wikimedia Foundation, Inc.
>
> jforres...@wikimedia.org | @jdforrester
>
> ___
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Similar articles feature performance in CirrusSearch for apps and mobile web

[Jon Katz]

On Thu, Feb 18, 2016 at 5:01 PM, Erik Bernhardson <
ebernhard...@wikimedia.org> wrote:

> Back testing thousands of user queries and comparing them to user click
> through or satisfaction (clickthrough + dwell)


Thanks, Erik!  This is very helpful.  What do you mean by 'back testing'?

Also, even without boost links, there seems to be a bias towards popular
(long pages).  it seems that a focus on # of words in common rather than %
is one of the things leading to long articles seeing so much more traction
- would this be an easy thing to test as well?
-J
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Similar articles feature performance in CirrusSearch for apps and mobile web

[Jon Katz]

Thanks both!  This clarifies a lot. I think the primary issue that editors
had raised and I had hoped to explore was popularity/importance v.
obscurity.

Specifically, there have been concerns that the results tilt towards more
popular articles (here
<https://www.mediawiki.org/wiki/Topic:Swjyfj59pkjfol7m> and here
<https://www.mediawiki.org/wiki/Topic:Sxy84nxinxqqld2i>), but it seems that
page traffic is not a variable.  Instead, what seems to be happening is
that the raw # of similar terms is being used, rather than the % of similar
terms.  This means that longer articles are favored.  Is that a fair
assessment?

-J

On Thu, Feb 18, 2016 at 4:15 PM, Gergo Tisza <gti...@wikimedia.org> wrote:

> On Thu, Feb 18, 2016 at 4:00 PM, Jon Katz <jk...@wikimedia.org> wrote:
>
>> Can someone on this list point me to where the more-like code sits? Or
>> better, yet would be someone documenting the rules that govern
>> prioritization of suggestions.
>>
>> I would like to document the logic for our communities so that we can
>> have an open discussion about what variables and weighting we should use to
>> suggest articles.
>>
>
> "More like" is an Elasticsearch
> <https://en.wikipedia.org/wiki/Elasticsearch> feature; the
> documentation is here
> <https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-mlt-query.html>.
> I'd imagine the source code is way too complicated to give much insight to
> the casual reader (as Elasticsearch is a large and complex piece of
> software) but I never looked into the ES codebase so that's just a guess.
> The configuration we use for morelike queries is here
> <https://github.com/wikimedia/mediawiki-extensions-CirrusSearch/blob/867248ccf522541922507f23a9ddd0783bed3699/CirrusSearch.php#L450>.
> The wrapper code that fires the ES query is here
> <https://github.com/wikimedia/mediawiki-extensions-CirrusSearch/blob/867248ccf522541922507f23a9ddd0783bed3699/includes/Searcher.php#L800>
>  (but
> at a glance it doesn't do anything interesting).
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Similar articles feature performance in CirrusSearch for apps and mobile web

[Jon Katz]

Hi,
Can someone on this list point me to where the more-like code sits? Or
better, yet would be someone documenting the rules that govern
prioritization of suggestions.

I would like to document the logic for our communities so that we can have
an open discussion about what variables and weighting we should use to
suggest articles.
-J

On Mon, Feb 15, 2016 at 11:26 AM, Dmitry Brant  wrote:

> Just a quick note that our latest production release (just published)
> contains this A/B test, in addition to the other updates.
> Looking forward to seeing the numbers from this!
>
> -Dmitry
>
>
> On Sun, Jan 31, 2016 at 9:35 PM, Dmitry Brant 
> wrote:
>
>> Roger that! I think we could squeeze it in -- the change would be pretty
>> straightforward. We'll be able to release a Beta with this A/B test in
>> short order, but it will probably be a couple weeks until our next
>> production release. I hope that's all right.
>>
>>
>> On Sat, Jan 30, 2016 at 1:02 PM, Gabriel Wicke 
>> wrote:
>>
>>> We are also happy to add cached entry points for high-traffic end
>>> points in the REST API. I commented to that effect at
>>> https://phabricator.wikimedia.org/T124216#1984206. Let us know if you
>>> think this would be useful for this use case.
>>>
>>> On Sat, Jan 30, 2016 at 8:11 AM, Adam Baso  wrote:
>>> > Okay. As per https://phabricator.wikimedia.org/T124225#1984080 I
>>> think if
>>> > we're doing near term experimentation with a controlled A/B test the
>>> Android
>>> > app is the only logical place to start. Dmitry, can that work for you?
>>> It's
>>> > not required, but I think it would be neat to see if we can move the
>>> needle
>>> > even more. Of course your quarterly goals take top priority...but what
>>> do
>>> > you think?
>>> >
>>> > On Sat, Jan 23, 2016 at 5:58 AM, Adam Baso 
>>> wrote:
>>> >>
>>> >> Hey all, am planning to look at Phabricator tasks and provide a reply
>>> >> during the upcoming weekdays. Just wanted to acknowledge I saw your
>>> replies!
>>> >>
>>> >>
>>> >> On Friday, January 22, 2016, Erik Bernhardson <
>>> ebernhard...@wikimedia.org>
>>> >> wrote:
>>> >>>
>>> >>> On Thu, Jan 21, 2016 at 1:29 AM, Joaquin Oltra Hernandez
>>> >>>  wrote:
>>> 
>>>  Regarding the caching, we would need to agree between apps and web
>>> about
>>>  the url and smaxage parameter as Adam noted so that the urls are
>>> exactly the
>>>  same to not bloat varnish and reuse the same cached objects across
>>>  platforms.
>>> 
>>>  It is an extremely adhoc and brittle solution but seems like it
>>> would be
>>>  the greatest win.
>>> 
>>>  20% of the traffic from searches by being only in android and web
>>> beta
>>>  seems a lot to me, and we should work on reducing it, otherwise
>>> when it hits
>>>  web stable we're going to crush the servers, so caching seems the
>>> highest
>>>  priority.
>>> 
>>> >>> To clarify its 20% of the load, as opposed to 20% of the traffic. But
>>> >>> same difference :)
>>> >>>
>>> 
>>>  Let's chime in https://phabricator.wikimedia.org/T124216 and
>>> continue
>>>  the cache discussion there.
>>> 
>>>  Regarding the validity of results with opening text only, how
>>> should we
>>>  proceed? Adam?
>>> 
>>> >>> I've put together https://phabricator.wikimedia.org/T124258 to track
>>> >>> putting together an AB test that measures the difference in click
>>> through
>>> >>> rates for the two approaches.
>>> >>>
>>> >>>
>>> 
>>>  On Wed, Jan 20, 2016 at 9:34 PM, David Causse <
>>> dcau...@wikimedia.org>
>>>  wrote:
>>> >
>>> > Hi,
>>> >
>>> > Yes we can combine many factors, from templates (quality but also
>>> > disambiguation/stubs), size and others.
>>> > Today cirrus uses mostly the number of incoming links which (imho)
>>> is
>>> > not very good for morelike.
>>> > On enwiki results will also be scored according the weights
>>> defined in
>>> >
>>> https://en.wikipedia.org/wiki/MediaWiki:Cirrussearch-boost-templates.
>>> >
>>> > I wrote a small bash to compare results :
>>> > https://gist.github.com/nomoa/93c5097e3c3cb3b6ebad
>>> > Here is some random results from the list (Semetimes better,
>>> sometimes
>>> > worse) :
>>> >
>>> > $ sh morelike.sh Revolution_Muslim
>>> > Defaults
>>> > "title": "Chess",
>>> > "title": "Suicide attack",
>>> > "title": "Zachary Adam Chesser",
>>> > ===
>>> > Opening text no boost links
>>> > "title": "Hungarian Revolution of 1956",
>>> > "title": "Muslims for America",
>>> > "title": "Salafist Front",
>>> >
>>> > $ sh morelike.sh Chesser
>>> > Defaults
>>> > "title": "Chess",
>>> > "title": "Edinburgh",
>>> > "title": "Edinburgh Corn 

Re: [WikimediaMobile] MobileWikiAppShareAFact event stream was: [Analytics] Stopping eventlogging events into MobileWikiAppShareAFact table

[Jon Katz]

+ Dmitry

Hi Nuria,
I will ask Dmitry to confirm, but I think a pause is fine for the next
couple of days as long as we are given the timestamps for outage can note
it on the schema wiki page.  Is this a sudden increase or has it always
been sending to high of a volume?  Regardless, I imagine a higher sampling
rate can probably be applied.
-J

On Tue, Dec 22, 2015 at 9:58 AM, Nuria Ruiz  wrote:

> Team:
>
> This  schema MobileWikiAppShareAFact is sending a lot of events, maybe is
> worth thinking whether we need that many. It is again a case where tables
> are becoming huge and hard to query fast.
>
> cc-ing Jon as schema owner.
>
> Can this data be sampled at a higher sampling rate? I have filed a ticket
> to this fact:
> https://phabricator.wikimedia.org/T14
>
> Thanks,
>
> Nuria
>
>
>
>
> On Tue, Dec 22, 2015 at 8:35 AM, Adam Baso  wrote:
>
>> Replacing mobile-tech with mobile-l (internal mobile-tech list
>> discontinued).
>>
>>
>> On Tuesday, December 22, 2015, Nuria Ruiz  wrote:
>>
>>> Team:
>>>
>>> As part of our effort of converting eventlogging mysql database to the
>>> tokudb engine we need to stop eventlogging events from flowing into the 
>>> MobileWikiAppShareAFact
>>> table, we are using this one table to see how long the conversion will take
>>> in order to plan for a larger outage window.
>>>
>>>
>>> Let us know if data should be backfilled as it can be, we anticipate
>>> events will not flow into table for the better part of one day.
>>>
>>>
>>> Thanks,
>>>
>>> Nuria
>>>
>>>
>>>
>> ___
>> Mobile-l mailing list
>> Mobile-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>>
>>
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] simple english

[Jon Katz]

Hi Rupert,
Thanks for your input.  I agree that the switch should sit at the page
level rather than creating a universal setting.
-J

On Monday, December 14, 2015, rupert THURNER <rupert.thur...@gmail.com>
wrote:

> I like the idea. Where you envision to let the user switch easy between
> simple and normal? I d love to do this easy for every article not as a
> general setting.
>
> Rupert
> On Dec 11, 2015 21:13, "Jon Katz" <jk...@wikimedia.org
> <javascript:_e(%7B%7D,'cvml','jk...@wikimedia.org');>> wrote:
>
>> Hi Folks,
>>
>> TLDR: want to introduce the idea of surfacing simple english version of
>> wikipedia in a more prominent way to test if this appeals to our readers.
>>  no timeline, no action items, just an intro to the concept and a request
>> for feedback/suggestions.
>>
>> *Bakground:*
>> As a refresher/summary, as part of the reading team's strategic process
>> <https://www.mediawiki.org/wiki/Reading/Strategy>, we identified 4
>> reading strategies that we are exploring and want to test hypothesis that
>> will help us determine which strategies are more impactful.
>>
>> I am reviewing our strategy tests (i.e. tests that can help us determine
>> if a particular strategy is one we should focus on) and came across some
>> notes I made with Abbey (copied) around the potential strategy "Guided
>> Educational Experiences" that I wanted to surface and run by you. This
>> potential strategy is one where the reading team focuses on enhancing
>> learning (comprehension and/or retention) of content.  Ideas in this theme
>> include identifying prerequisite articles, a suggested order to reading
>> articles (curricula), simple or practical versions of articles, quizzes or
>> even games. To be clear, this is a potential strategy that we are
>> evaluating along with others, as described here
>> <https://www.mediawiki.org/wiki/Reading/Strategy/Strategy_Process/Testing#About>.
>> I also want to acknowledge that there have likely been other experiments in
>> this area--if you have specific examples you would like to share, please do
>> so.  The test proposed below came about from one such awareness.
>>
>> *The test:*
>> One idea for this strategy was "simplified versions of
>> articles"--versions of articles for readers who were unfamiliar with the
>> topic or lacked a basic educational foundation.  That wikipedia articles
>> are sometimes to advanced is not a novel observation, but it's a tough nut
>> to crack.
>>
>> We had originally framed the test as "will editors want to create
>> simplified versions of articles" and we planned on asking them.  However
>> the work that James Helman is doing with editors translating medical
>> documents into more practical guides in Swahili [link?] seems to show there
>> is interest here.  However, we felt that SimpleEnglish was, in itself, a
>> remarkable test of what is being proposed, even though its focus is on
>> simple wording rather than concept simplicity. The most often-cited problem
>> (anecdote) with SimpleEnglish is that very few readers can find it.  This
>> makes sense: someone confused by sophisticated vocabulary or looking for a
>> summary of an article is not likely to check the language list to see if a
>> simple version of the article sits there.
>>
>> So the proposed test would be to surface simple english in a more
>> prominent way and to test if this led to higher comprehension using either
>> quick surveys or a proxy, like pageviews. I added the broad outlines of the
>> test to our strategy test document, here
>> <https://www.mediawiki.org/wiki/Reading/Strategy/Strategy_Process/Testing#Create_deep-dive_.28guided.29_educational_experience>
>> .
>>
>> *The ask:*
>> This is not part of our proposed Q3 plans or even our Q4 plans, but I
>> would like to hear feedback and ideas around how we could effectively
>> integrate it into our plans.  One idea would be to implement it on one of
>> the apps, first, since we can move things around there without disturbing
>> as many people.  We are open to suggestions.
>>
>> Best,
>>
>> J
>>
>>
>>
>>
>> ___
>> Mobile-l mailing list
>> Mobile-l@lists.wikimedia.org
>> <javascript:_e(%7B%7D,'cvml','Mobile-l@lists.wikimedia.org');>
>> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>>
>>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] simple english

[Jon Katz]

Hi Folks,

TLDR: want to introduce the idea of surfacing simple english version of
wikipedia in a more prominent way to test if this appeals to our readers.
 no timeline, no action items, just an intro to the concept and a request
for feedback/suggestions.

*Bakground:*
As a refresher/summary, as part of the reading team's strategic process
, we identified 4 reading
strategies that we are exploring and want to test hypothesis that will help
us determine which strategies are more impactful.

I am reviewing our strategy tests (i.e. tests that can help us determine if
a particular strategy is one we should focus on) and came across some notes
I made with Abbey (copied) around the potential strategy "Guided
Educational Experiences" that I wanted to surface and run by you. This
potential strategy is one where the reading team focuses on enhancing
learning (comprehension and/or retention) of content.  Ideas in this theme
include identifying prerequisite articles, a suggested order to reading
articles (curricula), simple or practical versions of articles, quizzes or
even games. To be clear, this is a potential strategy that we are
evaluating along with others, as described here
.
I also want to acknowledge that there have likely been other experiments in
this area--if you have specific examples you would like to share, please do
so.  The test proposed below came about from one such awareness.

*The test:*
One idea for this strategy was "simplified versions of articles"--versions
of articles for readers who were unfamiliar with the topic or lacked a
basic educational foundation.  That wikipedia articles are sometimes to
advanced is not a novel observation, but it's a tough nut to crack.

We had originally framed the test as "will editors want to create
simplified versions of articles" and we planned on asking them.  However
the work that James Helman is doing with editors translating medical
documents into more practical guides in Swahili [link?] seems to show there
is interest here.  However, we felt that SimpleEnglish was, in itself, a
remarkable test of what is being proposed, even though its focus is on
simple wording rather than concept simplicity. The most often-cited problem
(anecdote) with SimpleEnglish is that very few readers can find it.  This
makes sense: someone confused by sophisticated vocabulary or looking for a
summary of an article is not likely to check the language list to see if a
simple version of the article sits there.

So the proposed test would be to surface simple english in a more prominent
way and to test if this led to higher comprehension using either quick
surveys or a proxy, like pageviews. I added the broad outlines of the test
to our strategy test document, here

.

*The ask:*
This is not part of our proposed Q3 plans or even our Q4 plans, but I would
like to hear feedback and ideas around how we could effectively integrate
it into our plans.  One idea would be to implement it on one of the apps,
first, since we can move things around there without disturbing as many
people.  We are open to suggestions.

Best,

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

Re: [WikimediaMobile] Some interesting stuff from Google

[Jon Katz]

Thanks, Luis!

A search for Barack Obama surfaces a news carousel of AMPed articles that
push us down significantly (see link below on a mobile device).

Greater web speeds on mobile overall are a good thing for internet users
and put pressure on us to move fast or be punished.  Since I know nothing
for wmf projects is being implemented to this end before February, we'll
have to watch carefully to see how this impacts our search traffic (i.e.
most of our traffic) is impacted when google rolls it out.

https://www.google.com/webhp?esrch=AcceleratedMobilePages::Preview,AcceleratedMobilePagesDesktop::Promo#esrch=AcceleratedMobilePages::Preview%2CAcceleratedMobilePagesDesktop::Promo=barack+obama

On Wed, Dec 9, 2015 at 12:41 PM, Luis Villa <lvi...@wikimedia.org> wrote:

> On Mon, Oct 12, 2015 at 12:50 PM, Volker Eckl <ve...@wikimedia.org> wrote:
>
>> Google will give an introduction on AMP at SFHTML5 Meetup on 23 Oct:
>> http://www.meetup.com/de/sfhtml5/events/219966898/
>>
>> I'm in.
>>
>
> FWIW, Google appears to be serious about this:
> http://searchengineland.com/google-amp-coming-rank-fast-238046
>
> Luis
>
>
>> On Fri, Oct 9, 2015 at 6:43 PM, Jon Katz <jk...@wikimedia.org> wrote:
>>
>>>
>>> On Fri, Oct 9, 2015 at 12:34 AM, Joaquin Oltra Hernandez <
>>> jhernan...@wikimedia.org> wrote:
>>>
>>>> If you really wanted to, you can subset what you send to mobile
>>>> browsers and get the same benefits (provided you use a really good CDN).
>>>
>>>
>>> I think this announcement + the transcoding work Google is doing show
>>> that this ^ is something we should be strongly considering. If google can
>>> transcode our content and make it significantly faster (as Gergo showed in
>>> another thread) and/or other sites are adopting similar technology, than
>>> our users are going to expect a level of speed far higher than we can
>>> currently provide.  I don't care if we use google's or our own, but do want
>>> to make sure we aren't rebuilding the wheel if we don't have to.
>>>
>>> The conversations as to whether or not google is acting out of self
>>> interest are fairly moot (they are...always), but I think Luis's points are
>>> very apt about googles self interests being more closely aligned with ours
>>> on the web than the other big players in this space.
>>>
>>> On Fri, Oct 9, 2015 at 9:27 AM, Luis Villa <lvi...@wikimedia.org> wrote:
>>>
>>>> On Thu, Oct 8, 2015 at 5:39 PM, Toby Negrin <tneg...@wikimedia.org>
>>>> wrote:
>>>>
>>>>> Hi Luis --
>>>>>
>>>>> I honestly don't see a lot of difference between Google, Twitter and
>>>>> Facebook, since they are all ad supported entities with a fiscal
>>>>> responsibility to track their users and sell the data. Apple's a bit
>>>>> different on the surface since they have a different business model. I
>>>>> agree that these are bad for the internet but so are incredibly slow web
>>>>> pages that make apps essentially required for a good experience.
>>>>>
>>>>
>>>> I agree that the companies all have (essentially[1]) the same motives
>>>> at the company level. The difference is that Google's technical approach to
>>>> solving the latency problem is not explicitly tied to Google or to
>>>> particular Google apps. (There is a pure web demo, for example, which works
>>>> in any mobile browser, including Firefox for Android, and Twitter - a
>>>> Google competitor - has already adopted it.) In contrast, Facebook and
>>>> Apple's "solutions" for fast reading are very explicitly tied to (1) apps,
>>>> not browsers, and (2) apps specifically from those companies. There will
>>>> never be a future where Facebook's solution for latency works outside of
>>>> Facebook; there is (at least in theory, and possibly in practice w/
>>>> Twitter) such a future with AMP.
>>>>
>>>> Or to put it another way: Google's solution still might not be good,
>>>> but it's at least possible that it could keep content on the open web;
>>>> Facebook and Apple are pretty explicitly trying to kill the open web. There
>>>> is no way the long game of the FB/Apple apps lead to good outcomes for
>>>> independent publishers like us.
>>>>
>>>>
>>>>> On the analytics, this would probably not include their use of our
>>>>> content in the knowledge graph or

Re: [WikimediaMobile] [Android application]Project WikiJourney

[Jon Katz]

Excellent, Paul!

   - thanks for the link - I'll try the beta app and give feedback
   - as far as Gather goes, we will be starting to implement it in the
   Android app starting in January, so hopefully lessons learned there will
   apply to you as well (and vice verse)


On Wed, Dec 9, 2015 at 5:30 AM, Joaquin Oltra Hernandez <
jhernan...@wikimedia.org> wrote:

> Hi Paul,
>
> Awesome job! I'll install it later and try it out!
>
>   because we just suceeded in integrating OAuth (which is quite a
> success, because OAuth implementation was a nightmare...).
>
> Do you have a blog post or page where you've detailed the process and what
> was so bad about it? If not, would you mind expanding?
>
> I feel this feedback would be great for other developers trying to build
> on top of the platform and for WMF devs to improve the third party login
> story!
>
> Thanks
> On Dec 9, 2015 9:41 AM, "Paul Arzelier" <paul.arzel...@free.fr> wrote:
>
>> So, as I said previously, after one year of development, the WikiJourney
>> app, made in order to promote free tourism, is out!
>> Okay, it's still a little bit buggy, but that's why we need it tested
>> over different devices...
>>
>> https://play.google.com/store/apps/details?id=com.wikijourney.wikijourney
>>
>> Try it if you want, and if you have any comment (negative or positive),
>> tell me or write it in the play store!
>>
>> (it's also available in aptoide/f-droid...)
>>
>> Paul
>>
>> Le 08/12/2015 00:23, Paul Arzelier a écrit :
>>
>> Oh, hi John!
>> Yes, we met at the hackathon, and we even improved the website we showed
>> you there: we even display wikivoyage guides around you! (
>> <https://www.wikijourney.eu/>https://www.wikijourney.eu/). (Well,
>> hopefully, because nine months without any update would have been kind of
>> sad haha)
>>
>> We'll need android beta-testers soon, and maybe some guidance on
>> special:gather, because we just suceeded in integrating OAuth (which is
>> quite a success, because OAuth implementation was a nightmare...).
>> Overall, we mainly used wikidata query editor, which was really easy to
>> use.
>> What we needed was 1) get points of interests around a specific location
>> (which the « around » call helped a lot), 2) Get tourism-related
>> wikidata/wikipedia infos of those POI's, which is quite simple. We even
>> made a little wrapper/api to get directly these informations:
>> https://github.com/WikiJourney/wikijourney_website/wiki/API-:-How-does-it-work%3F
>>
>> However, as I said, we may need some help integrating collections, but
>> we'll post questions on appropriate sections :)
>>
>> Thanks for your answers - the app should be in beta in the play store
>> tomorrow.
>>
>> Paul
>>
>> Le 07/12/2015 23:49, Jon Katz a écrit :
>>
>> Hey,
>> You guys started at the hackathon right?  It is so great to hear it is
>> coming along and I look forward to using it as well.
>> -J
>>
>> On Mon, Dec 7, 2015 at 2:25 PM, Jon Robson <jrob...@wikimedia.org> wrote:
>>
>>> I'm not an app developer but if you need a beta tester or any specific
>>> guidance on how you are using the API please let me know. It would also be
>>> great to hear from you what pain points you ran into whilst building this -
>>> specifically it would be good to understand we can improve in MediaWiki's
>>> API to better support what you are trying to do.
>>>
>>> On Fri, Dec 4, 2015 at 9:45 AM, Paul Arzelier < <paul.arzel...@free.fr>
>>> paul.arzel...@free.fr> wrote:
>>>
>>>> Yes!
>>>> Because we don't know if it's well-written enough so that someone who's
>>>> not in the project could read, understand what our code is doing and modify
>>>> it without much trouble...
>>>>
>>>> Regards,
>>>> Paul
>>>>
>>>>
>>>> Le 04/12/2015 18:19, Toby Negrin a écrit :
>>>>
>>>> Hi Paul -- Are you asking for some sort of code or architecture review
>>>> for your application?
>>>>
>>>> Best,
>>>>
>>>> -Toby
>>>>
>>>> On Fri, Dec 4, 2015 at 1:26 AM, Paul Arzelier < <paul.arzel...@free.fr>
>>>> paul.arzel...@free.fr> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I'm currently developing, with some friends, an application called
>>>>> WikiJourney to promote « free » (as in a speech) tourism. Fo

Re: [WikimediaMobile] MobileWebClickTracking schema

[Jon Katz]

Apologies: my email below was referring to a table different from the one
Nuria was asking about.  No objections from me to remove the table you were
discussing.

On Fri, Dec 4, 2015 at 2:09 PM, Jon Katz <jk...@wikimedia.org> wrote:

> To confirm, this schema is still alive and growing--removing search from
> it would help with size:
>
> Here is the most current table:
> MobileWebUIClickTracking_10742159
>
> On Fri, Dec 4, 2015 at 1:15 PM, Jon Robson <jdlrob...@gmail.com> wrote:
>
>> That said I'm confused to see 3 events for 27th November 2015 from
>> Russian and English Wikipedia so this table is growing - but I suspect
>> this might be due to some mirror site?
>>
>>
>> On Fri, Dec 4, 2015 at 1:13 PM, Jon Robson <jdlrob...@gmail.com> wrote:
>> > Jon This table isn't used to my knowledge any more.
>> > MobileWebUIClickTracking tracks clicks to hamburger/search/language
>> etc..
>> > MobileWebMainMenuClickTracking_11568715 clicks inside menu
>> > MobileWebWatchlistClickTracking_10720361 inside watchlist feature
>> >
>> > MobileWebDiffClickTracking_10720373 within diff
>> > The discovery team has MobileWebSearch_12054448 which tracks search
>> behaviour.
>> >
>> >
>> > On Fri, Dec 4, 2015 at 12:09 PM, Jon Katz <jk...@wikimedia.org> wrote:
>> >> I think we should remove search events from it, but currently this is
>> the
>> >> only schema that tracks article-level actions.
>> >>
>> >> A while back we shrunk its predecessor by removing the hamburger menu
>> >> actions, but the search actions account for the vast bulk of this
>> table.
>> >> Now that there is a separate search action table, I think we can remove
>> >> search and shrink the table dramatically.
>> >> -J
>> >>
>> >> On Fri, Dec 4, 2015 at 11:24 AM, Nuria Ruiz <nu...@wikimedia.org>
>> wrote:
>> >>>
>> >>> Team:
>> >>>
>> >>> This schema
>> https://meta.wikimedia.org/wiki/Schema:MobileWebClickTracking
>> >>> has a lot of data in eventlogging. Tables are getting huge.
>> >>> Too huge to be queried.
>> >>>
>> >>> I remember that we agreed to split this schema in several others, can
>> we
>> >>> do away with this schema now?
>> >>>
>> >>> Thanks,
>> >>>
>> >>> ___
>> >>> Mobile-l mailing list
>> >>> Mobile-l@lists.wikimedia.org
>> >>> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>> >>>
>> >>
>> >>
>> >> ___
>> >> 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
>>
>>
>>
>> --
>> 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

Re: [WikimediaMobile] MobileWebClickTracking schema

[Jon Katz]

To confirm, this schema is still alive and growing--removing search from it
would help with size:

Here is the most current table:
MobileWebUIClickTracking_10742159

On Fri, Dec 4, 2015 at 1:15 PM, Jon Robson <jdlrob...@gmail.com> wrote:

> That said I'm confused to see 3 events for 27th November 2015 from
> Russian and English Wikipedia so this table is growing - but I suspect
> this might be due to some mirror site?
>
>
> On Fri, Dec 4, 2015 at 1:13 PM, Jon Robson <jdlrob...@gmail.com> wrote:
> > Jon This table isn't used to my knowledge any more.
> > MobileWebUIClickTracking tracks clicks to hamburger/search/language etc..
> > MobileWebMainMenuClickTracking_11568715 clicks inside menu
> > MobileWebWatchlistClickTracking_10720361 inside watchlist feature
> >
> > MobileWebDiffClickTracking_10720373 within diff
> > The discovery team has MobileWebSearch_12054448 which tracks search
> behaviour.
> >
> >
> > On Fri, Dec 4, 2015 at 12:09 PM, Jon Katz <jk...@wikimedia.org> wrote:
> >> I think we should remove search events from it, but currently this is
> the
> >> only schema that tracks article-level actions.
> >>
> >> A while back we shrunk its predecessor by removing the hamburger menu
> >> actions, but the search actions account for the vast bulk of this table.
> >> Now that there is a separate search action table, I think we can remove
> >> search and shrink the table dramatically.
> >> -J
> >>
> >> On Fri, Dec 4, 2015 at 11:24 AM, Nuria Ruiz <nu...@wikimedia.org>
> wrote:
> >>>
> >>> Team:
> >>>
> >>> This schema
> https://meta.wikimedia.org/wiki/Schema:MobileWebClickTracking
> >>> has a lot of data in eventlogging. Tables are getting huge.
> >>> Too huge to be queried.
> >>>
> >>> I remember that we agreed to split this schema in several others, can
> we
> >>> do away with this schema now?
> >>>
> >>> Thanks,
> >>>
> >>> ___
> >>> Mobile-l mailing list
> >>> Mobile-l@lists.wikimedia.org
> >>> https://lists.wikimedia.org/mailman/listinfo/mobile-l
> >>>
> >>
> >>
> >> ___
> >> 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
>
>
>
> --
> 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

Re: [WikimediaMobile] MobileWebClickTracking schema

[Jon Katz]

I think we should remove search events from it, but currently this is the
only schema that tracks article-level actions.

A while back we shrunk its predecessor by removing the hamburger menu
actions, but the search actions account for the vast bulk of this table.
Now that there is a separate search action table, I think we can remove
search and shrink the table dramatically.
-J

On Fri, Dec 4, 2015 at 11:24 AM, Nuria Ruiz  wrote:

> Team:
>
> This schema https://meta.wikimedia.org/wiki/Schema:MobileWebClickTracking has
> a lot of data in eventlogging. Tables are getting huge.
> Too huge to be queried.
>
> I remember that we agreed to split this schema in several others, can we
> do away with this schema now?
>
> Thanks,
>
> ___
> Mobile-l mailing list
> Mobile-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] scrapping the special:user profile page

[Jon Katz]

Hey Folks,
Based on the thread on this ticket, T119412
, it looks like we have
addressed all of the concerns raised and can move forward with scrapping
mobile's special:userprofile (T85929
) page in favor of:

   - a header that includes a link to the users contributions, and
   - if userpage exists: show userpage as is
   - if user page doesn't exist: prompts user to create their own (if it is
   them) or notifies them of the absence (if it is another user)

If we don't hear any concerns by Friday 6pm GMT, I will ask that the web
team scope the work to see if it can be included in our next sprint.

Best,

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

[WikimediaMobile] Tilman is joining the Reading Team!

[Jon Katz]

Hi Everyone,

I’m happy to announce that, as of today, Tilman Bayer has officially joined
the Reading product team as a Senior Analyst. He will increase our capacity
for understanding our users and the impact of our efforts through data
analysis. Tilman is responsible for:

   -

   generating our primary metrics and communicating them
   -

   consulting on, analyzing and communicating the results of
   feature-specific instrumentation
   -

   driving best practices within the team with regard to analysis (aided by
   his background in mathematics)


Tilman has been shadowing the team for about a quarter, and has ramped up
his involvement dramatically over the last month.  During this period,
Tilman has moved quickly and is already owning the analysis of a
significant number of our ongoing projects.

Tilman’s weekly reading metrics report (example
)
is currently being sent out to the Mobile-l mailing list (which serves as
the Reading team’s primary public mailing list). We are still gathering
feedback from the subscribers of that list and once we have a sustainable
and stable format, we hope to share more widely.

Tilman has been working with us since July 2011, and has been a Wikipedian
since 2003. He was an analyst on the Communications team until Erik Moeller
asked him to join Product & Strategy at the beginning of this year. Tilman
will be moving out of his current role in Terry’s department where he is
right now wrapping up the current round of quarterly reviews and
preparation of the organization-wide quarterly report for Q1.

Best,

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

Re: [WikimediaMobile] [reading-wmf] Browse Hypothesis Results

[Jon Katz]

Thanks, Joaquin!

On Tue, Oct 13, 2015 at 4:32 AM, Joaquin Oltra Hernandez <
jhernan...@wikimedia.org> wrote:

> Thanks a lot for the detailed report Jon.
>
> I've parsed it and posted it to
> https://www.mediawiki.org/wiki/Reading/Web/Projects/Categories_Browse so
> that can keep it more accessible than the mailing list archive
> <https://lists.wikimedia.org/pipermail/mobile-l/2015-October/009827.html>.
>
> Any help with formatting or text corrections would be appreciated.
>
>
> On Sun, Oct 11, 2015 at 8:32 PM, Jon Katz <jk...@wikimedia.org> wrote:
>
>> Hi Team,
>> I just wanted to update you on the results of something we internally
>> referred to as the '*browse' *prototype.
>> TLDR: as implemented the mobile 'browse by category' test did not drive
>> significant engagement.  In fact, as implemented, it seemed inferior to
>> blue links.  However, we started with a very rough and low-impact
>> prototype, so a few tweaks would give us more definitive results.
>>
>> Here is the doc from which I am pasting from below:
>> https://docs.google.com/document/d/1Mqw-awAcp01IcLhHPsHmWsqaAyK1l2-w_LMDtizyFQ4/edit?usp=sharing
>>
>> Questions/comments welcome!
>> Best,
>>
>> J
>>
>>
>> Browse Prototype Results
>>
>>
>> 
>>
>> Intro
>> <https://docs.google.com/document/d/1Mqw-awAcp01IcLhHPsHmWsqaAyK1l2-w_LMDtizyFQ4/edit#heading=h.6s40inyan02p>
>>
>> Process
>> <https://docs.google.com/document/d/1Mqw-awAcp01IcLhHPsHmWsqaAyK1l2-w_LMDtizyFQ4/edit#heading=h.d5x661n72t7d>
>>
>> Results
>> <https://docs.google.com/document/d/1Mqw-awAcp01IcLhHPsHmWsqaAyK1l2-w_LMDtizyFQ4/edit#heading=h.naqxa4etwhl4>
>>
>> Blue links in general
>> <https://docs.google.com/document/d/1Mqw-awAcp01IcLhHPsHmWsqaAyK1l2-w_LMDtizyFQ4/edit#heading=h.8nn07h675j3o>
>>
>> Category tags
>> <https://docs.google.com/document/d/1Mqw-awAcp01IcLhHPsHmWsqaAyK1l2-w_LMDtizyFQ4/edit#heading=h.gagragojxpiz>
>>
>> Conclusion and Next Steps
>> <https://docs.google.com/document/d/1Mqw-awAcp01IcLhHPsHmWsqaAyK1l2-w_LMDtizyFQ4/edit#heading=h.z3p82tg8enr>
>>
>> Process
>> <https://docs.google.com/document/d/1Mqw-awAcp01IcLhHPsHmWsqaAyK1l2-w_LMDtizyFQ4/edit#heading=h.ocqtfqhf8n0t>
>>
>> Do people want to browse by categories?
>> <https://docs.google.com/document/d/1Mqw-awAcp01IcLhHPsHmWsqaAyK1l2-w_LMDtizyFQ4/edit#heading=h.9ksw2zvt8q19>
>> 
>>
>>
>> Intro
>>
>> As outlined in this doc
>> <https://docs.google.com/presentation/d/1ZssE8G0P5WVg8XmkBTi5G3n4OdLHPFGWZDZFW5_DSS0/edit?usp=sharing>,
>> the concept is a tag that allows readers to navigate WP via categories that
>> are meaningful and populated in order of 'significance' (as determined by
>> user input).  The hypothesis:
>>
>>-
>>
>>users will want to navigate by category if there are fewer, more
>>meaningful categories per page and those category pages showed the most
>>‘notable’ members first.
>>
>> Again, see the full doc
>> <https://docs.google.com/presentation/d/1ZssE8G0P5WVg8XmkBTi5G3n4OdLHPFGWZDZFW5_DSS0/edit?usp=sharing>
>> to understand the premise.
>>
>> Process
>>
>> The first step was to validate: do users want to navigate via category?
>> So we built a very lightweight prototype on mobile web, en wikipedia
>> (stable, not beta) using hardcoded config variables, in the following
>> categories ( ~4000 pages).  Here we did not look into sub-categories
>> with one exception (see T94732 <https://phabricator.wikimedia.org/T94732>
>> for details).  There was also an error and 2 of the categories did not have
>> tags implemented (struck through, below)
>>
>> Category
>>
>> Pagecount
>>
>> NBA All Stars
>>
>> 400
>>
>> American Politicians
>>
>> 818
>>
>> Object-Oriented Programming Languages
>>
>> 164
>>
>> European States
>>
>> 24
>>
>> American Female Pop Singers
>>
>> 326
>>
>> American drama television series
>>
>> 1048
>>
>> Modern Painters
>>
>> 983
>>
>> Landmarks in San Francisco, California
>>
>> 270
>>
>>
>>
>> Here is how it appeared on the Alcatraz page
>>
>>
>> When the user clicked the tag, they were taken to a gather-like
>> collection based on manually estimated relevance
>>
>> (sorry cropped shot)
>>
>>
>>
>>
>> The c

Re: [WikimediaMobile] [reading-wmf] Browse Hypothesis Results

[Jon Katz]

Thanks for thinking through! Responses inline
On Tue, Oct 13, 2015 at 8:36 AM, Brian Gerstle <bgers...@wikimedia.org>
wrote:

> Great experiment!  A couple questions/comments:
>
>1. The % clickthrough per category shows SF Landmarks at 120%. Is that
>correct, and if so, what does it mean?
>
> It means that for every 10 times the SF Landmarks list was visited from a
tag, there were 12 clicks on to other articles (this is possible because a
user can visit 2 or more articles from the page by clicking on the 'back'
button in their browser)

>
>1. As a big believer in the power of categories as a driver for
>engagement, I would love to see more variations of this experiment w/
>different placements, in a feed, different categories, add'n of portals, as
>a FTUE, etc. (likely to have a great deal of overlap w/ cascade D: deep
>dive educational experience)
>
> Me too!  it is very hard to learn anything from a first stab like this

>
>1. Also loved the win/needs-improvement breakdown at the end
>
> Thanks!


>
> On Tue, Oct 13, 2015 at 11:23 AM, Jon Katz <jk...@wikimedia.org> wrote:
>
>> Thanks, Joaquin!
>>
>> On Tue, Oct 13, 2015 at 4:32 AM, Joaquin Oltra Hernandez <
>> jhernan...@wikimedia.org> wrote:
>>
>>> Thanks a lot for the detailed report Jon.
>>>
>>> I've parsed it and posted it to
>>> https://www.mediawiki.org/wiki/Reading/Web/Projects/Categories_Browse so
>>> that can keep it more accessible than the mailing list archive
>>> <https://lists.wikimedia.org/pipermail/mobile-l/2015-October/009827.html>
>>> .
>>>
>>> Any help with formatting or text corrections would be appreciated.
>>>
>>>
>>> On Sun, Oct 11, 2015 at 8:32 PM, Jon Katz <jk...@wikimedia.org> wrote:
>>>
>>>> Hi Team,
>>>> I just wanted to update you on the results of something we internally
>>>> referred to as the '*browse' *prototype.
>>>> TLDR: as implemented the mobile 'browse by category' test did not drive
>>>> significant engagement.  In fact, as implemented, it seemed inferior to
>>>> blue links.  However, we started with a very rough and low-impact
>>>> prototype, so a few tweaks would give us more definitive results.
>>>>
>>>> Here is the doc from which I am pasting from below:
>>>> https://docs.google.com/document/d/1Mqw-awAcp01IcLhHPsHmWsqaAyK1l2-w_LMDtizyFQ4/edit?usp=sharing
>>>>
>>>> Questions/comments welcome!
>>>> Best,
>>>>
>>>> J
>>>>
>>>>
>>>> Browse Prototype Results
>>>>
>>>>
>>>> 
>>>>
>>>> Intro
>>>> <https://docs.google.com/document/d/1Mqw-awAcp01IcLhHPsHmWsqaAyK1l2-w_LMDtizyFQ4/edit#heading=h.6s40inyan02p>
>>>>
>>>> Process
>>>> <https://docs.google.com/document/d/1Mqw-awAcp01IcLhHPsHmWsqaAyK1l2-w_LMDtizyFQ4/edit#heading=h.d5x661n72t7d>
>>>>
>>>> Results
>>>> <https://docs.google.com/document/d/1Mqw-awAcp01IcLhHPsHmWsqaAyK1l2-w_LMDtizyFQ4/edit#heading=h.naqxa4etwhl4>
>>>>
>>>> Blue links in general
>>>> <https://docs.google.com/document/d/1Mqw-awAcp01IcLhHPsHmWsqaAyK1l2-w_LMDtizyFQ4/edit#heading=h.8nn07h675j3o>
>>>>
>>>> Category tags
>>>> <https://docs.google.com/document/d/1Mqw-awAcp01IcLhHPsHmWsqaAyK1l2-w_LMDtizyFQ4/edit#heading=h.gagragojxpiz>
>>>>
>>>> Conclusion and Next Steps
>>>> <https://docs.google.com/document/d/1Mqw-awAcp01IcLhHPsHmWsqaAyK1l2-w_LMDtizyFQ4/edit#heading=h.z3p82tg8enr>
>>>>
>>>> Process
>>>> <https://docs.google.com/document/d/1Mqw-awAcp01IcLhHPsHmWsqaAyK1l2-w_LMDtizyFQ4/edit#heading=h.ocqtfqhf8n0t>
>>>>
>>>> Do people want to browse by categories?
>>>> <https://docs.google.com/document/d/1Mqw-awAcp01IcLhHPsHmWsqaAyK1l2-w_LMDtizyFQ4/edit#heading=h.9ksw2zvt8q19>
>>>> 
>>>>
>>>>
>>>> Intro
>>>>
>>>> As outlined in this doc
>>>> <https://docs.google.com/presentation/d/1ZssE8G0P5WVg8XmkBTi5G3n4OdLHPFGWZDZFW5_DSS0/edit?usp=sharing>,
>>>> the concept is a tag that allows readers to navigate WP via categories that
>>>> are meaningful and populated in order of 'significance' (as determined by
>>>> user input).  The hypothesis:
>>>>
>>>>-
>>>>
>>>>users will want to navigate by c

Re: [WikimediaMobile] [reading-wmf] Browse Hypothesis Results

[Jon Katz]

Thanks for thinking through this, Jon.  I think I made something
unclear--responses inline.  In green to make reading easier:

On Tue, Oct 13, 2015 at 8:58 AM, Jon Robson  wrote:

> Jon thanks so much for writing this up and thanks Joaquin for putting it
> on the wiki (you beat me to it :))
>
> I'm a little confused to the meaning of "tag impression" -  does it mean
> they rendered or that the user saw them?
>

User saw them, or, more specifically, appeared on screen.


> If the latter...
>
> https://www.mediawiki.org/wiki/Reading/Web/Projects/Categories_Browse#/media/File:Browse-Views_and_clickthrough.png
> suggests that 50% of the time a reader saw a tag (.45% of the time) (there
> was a tag impression) they clicked on them (0.18%). Am I misunderstanding
> what tag impression means?
>

Sorry, this graph is a little confusing because it has 2 axes.  The red
(impressions) corresponds to the right axis and the blue (% click-through)
is the left- axis.  So, the way to read it is that there were ~50,000
impressions a day, and the click-thru rate was .18%.  This means that for
every ~1000 times a tag appeared to a user, ~2 clicks occurred.  The
question of what % of pageviews resulted in an 'impression' is a really
good one - I think it could be easily looked up using the pageview_hourly
table.

>
> Is this a fair summary?:
> "When the tags were __visible__ to the user, 30-50% of the time they
> clicked through to the "category page". On this page only 40% of visits
> resulted in a click to an article in the list.
>
No--for reasons explained above.

>
> To me this is significant traffic... especially if made more visible.
> I personally would expect normal link traffic to be higher and for this to
> be a new source of engagement.
>
Yes, it would be hard to get higher click-through than our current
engagement model, but anything additive represents not only massive
numbers, but an opportunity to have our users increasingly think of us as a
place to learn (rather than a simple question and answer)


>
> Can we clarify this on the wiki page and in this thread as I fear I'm
> misunderstanding something..?
>

Yes--will add clarity to the graph on wiki.  It might be awhile, however,
before I have the brain and time to execute the query your question brought
up of "what % of total pages lead to the tag being shown"?  This will just
as easily be answered by the read more data you will be implementing.


>
> Other questions:
> * What was the number of clicks to tags per visit? (were being opening new
> tabs or clicking on one?)
>
I don't understand this question.  I know we can't track 'visits'.
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Browse Hypothesis Results

[Jon Katz]

Hi Team,
I just wanted to update you on the results of something we internally
referred to as the '*browse' *prototype.
TLDR: as implemented the mobile 'browse by category' test did not drive
significant engagement.  In fact, as implemented, it seemed inferior to
blue links.  However, we started with a very rough and low-impact
prototype, so a few tweaks would give us more definitive results.

Here is the doc from which I am pasting from below:
https://docs.google.com/document/d/1Mqw-awAcp01IcLhHPsHmWsqaAyK1l2-w_LMDtizyFQ4/edit?usp=sharing

Questions/comments welcome!
Best,

J


Browse Prototype Results




Intro


Process


Results


Blue links in general


Category tags


Conclusion and Next Steps


Process


Do people want to browse by categories?




Intro

As outlined in this doc
,
the concept is a tag that allows readers to navigate WP via categories that
are meaningful and populated in order of 'significance' (as determined by
user input).  The hypothesis:

   -

   users will want to navigate by category if there are fewer, more
   meaningful categories per page and those category pages showed the most
   ‘notable’ members first.

Again, see the full doc

to understand the premise.

Process

The first step was to validate: do users want to navigate via category?  So
we built a very lightweight prototype on mobile web, en wikipedia (stable,
not beta) using hardcoded config variables, in the following categories ( ~4000
pages).  Here we did not look into sub-categories with one exception (see
T94732  for details).  There was
also an error and 2 of the categories did not have tags implemented (struck
through, below)

Category

Pagecount

NBA All Stars

400

American Politicians

818

Object-Oriented Programming Languages

164

European States

24

American Female Pop Singers

326

American drama television series

1048

Modern Painters

983

Landmarks in San Francisco, California

270



Here is how it appeared on the Alcatraz page


When the user clicked the tag, they were taken to a gather-like collection
based on manually estimated relevance

(sorry cropped shot)




The category pages were designed to show the most relevant (as deemed by
me) to the broadest audience, first. Here is the ordering:
https://docs.google.com/spreadsheets/d/12xLXQsH1zcg6E8lDuSonumZNdBvfaBuHOS1a1TCASK4/edit#gid=0

This was intended to lie in contrast with our current category pages, which
are alphabetical and not really intended for human browsing:
https://en.wikipedia.org/wiki/Category:American_male_film_actors


We primarily measured a few things:


   -

   when a tag was seen by a user
   -

   when a tag was clicked on by a user
   -

   when a page in the new ‘category view’ was clicked on by a user


As a side effort, I looked to see if overall referrals from pages with tags
went up--this was a timed intervention rather than an a/b test and given
the click-thru on the tags, the impact would have been negligible anyway.
This was confirmed by some very noisy results.


Results
Blue links in general

One benefit of the side study mentioned in the previous paragraph is that I
was able to generate a table that looked at the pages in question before we
started the test that shows a ratio of total pageviews/pageviews referred
by a page (estimate of how many links were opened from that page).  Though
it is literally just for 0-1 GMT, 6/29/15, now  that we have the pageview
hourly table, a more robust analysis can tell us how categories differ in
this regard:


Category

links clicked

#pvs

clicks/pvs

Category:20th-centuryAmericanpoliticians

761

1243

61%

Category:Americandramatelevisionseries

5981

8844

68%

Category:Americanfemalepopsingers

2502

4280

58%

Category:LandmarksinSanFrancisco,

104

287

36%

Category:Modernpainters

136

369

37%

Category:NationalBasketballAssociationAll-Stars

1908

3341

57%

Re: [WikimediaMobile] Some interesting stuff from Google

[Jon Katz]

On Fri, Oct 9, 2015 at 12:34 AM, Joaquin Oltra Hernandez <
jhernan...@wikimedia.org> wrote:

> If you really wanted to, you can subset what you send to mobile browsers
> and get the same benefits (provided you use a really good CDN).


I think this announcement + the transcoding work Google is doing show that
this ^ is something we should be strongly considering. If google can
transcode our content and make it significantly faster (as Gergo showed in
another thread) and/or other sites are adopting similar technology, than
our users are going to expect a level of speed far higher than we can
currently provide.  I don't care if we use google's or our own, but do want
to make sure we aren't rebuilding the wheel if we don't have to.

The conversations as to whether or not google is acting out of self
interest are fairly moot (they are...always), but I think Luis's points are
very apt about googles self interests being more closely aligned with ours
on the web than the other big players in this space.

On Fri, Oct 9, 2015 at 9:27 AM, Luis Villa  wrote:

> On Thu, Oct 8, 2015 at 5:39 PM, Toby Negrin  wrote:
>
>> Hi Luis --
>>
>> I honestly don't see a lot of difference between Google, Twitter and
>> Facebook, since they are all ad supported entities with a fiscal
>> responsibility to track their users and sell the data. Apple's a bit
>> different on the surface since they have a different business model. I
>> agree that these are bad for the internet but so are incredibly slow web
>> pages that make apps essentially required for a good experience.
>>
>
> I agree that the companies all have (essentially[1]) the same motives at
> the company level. The difference is that Google's technical approach to
> solving the latency problem is not explicitly tied to Google or to
> particular Google apps. (There is a pure web demo, for example, which works
> in any mobile browser, including Firefox for Android, and Twitter - a
> Google competitor - has already adopted it.) In contrast, Facebook and
> Apple's "solutions" for fast reading are very explicitly tied to (1) apps,
> not browsers, and (2) apps specifically from those companies. There will
> never be a future where Facebook's solution for latency works outside of
> Facebook; there is (at least in theory, and possibly in practice w/
> Twitter) such a future with AMP.
>
> Or to put it another way: Google's solution still might not be good, but
> it's at least possible that it could keep content on the open web; Facebook
> and Apple are pretty explicitly trying to kill the open web. There is no
> way the long game of the FB/Apple apps lead to good outcomes for
> independent publishers like us.
>
>
>> On the analytics, this would probably not include their use of our
>> content in the knowledge graph or elsewhere
>>
>
> Oh, definitely won't. But it might give us some leverage in those
> discussions - having conceded that the analytics from some cached pages
> should be shared, it is no longer such a huge leap to analytics on other
> types of "cached"/processed data.
>
>
>> and also might be troublesome for those who prefer google not to track
>> their reading.
>>
>
> There is a lot of devil in those details, of course, but for those coming
> from Google Search (still the vast majority of our users) the first leap is
> already tracked/known to Google. This doesn't necessarily make that worse.
> (Much depends on how the caching occurs; their ability to track the
> *second* page you read would be new, at least for iOS users - Android users
> already have this problem, I believe.)
>
>
>> Bryan's ticket is a good embarkation point for thinking about supporting
>> new clients; Reading is also planning some Reading infrastructure work for
>> the summit which could relate[1]
>>
>
>> [1] https://phabricator.wikimedia.org/T114542
>>
>
> Great link, thanks.
>
> [1] The subtle difference, from our perspective, is that Google has pretty
> strong incentives to keep the open web viable, because making sense of (and
> selling ads on) the open web is their core competence. Facebook and Apple,
> in contrast, have no strategic reason to keep the open web viable: if they
> can turn every publisher into a FB-only or Apple-only publisher, they'd
> happily do that. Of course, an open web that doesn't depend on Google would
> be even better, but that's not in the cards at this point unless Mozilla
> wakes up.
>
>
>
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Oct 8, 2015 at 2:02 PM, Luis Villa  wrote:
>>
>>> Toby -
>>>
>>> I'm generally 1000% on-board with slow follower for anything
>>> user-facing. The only reason I might make an exception here is because the
>>> competitors you mention are all pretty awful for the web generally, and
>>> this has uptake already from Google and Twitter. (Two isn't great, but two
>>> + slim opportunity for growth is way better than the guaranteed
>>> never-greater-than-1 we'll see from FB's option.)
>>>
>>> 

Re: [WikimediaMobile] Readership metrics for the week until September 20, 2015

[Jon Katz]

+ Analytics

Tilman, this is great.  I find myself enjoying the stats/graphs and
analysis/commentary equally and so far I don't see anything that isn't very
helpful.  Two considerations:

   - Two app-level metrics I would like to see moving forward would be a
   number showing a daily/monthly visit count divided by the install base (if
   it is achievable): 15% of Android users visit every day, 45% visit every
   month. Along those lines, I am very interested to see the retention data
   that Android is now collecting.

   - Ultimately, I think 30 day views (or 28 day views) are less subject to
   noise than 7-day.


   - On a related note, so far the weekly cadence is great.  It might also
   be that after 3 weeks we realize that a biweekly or monthly cadence is all
   we really need.

At some point, we will have to solidify this so that we can automate
some/most of it.  Perhaps we should chat offline about what your tolerance
is in that regard.

-J

On Wed, Sep 23, 2015 at 12:26 AM, Tilman Bayer  wrote:

> Hi all,
>
> here is the weekly look at our most important readership metrics.
>
> As laid out last week, the main purpose is to raise awareness about how
> these are developing, call out the impact of any unusual events in the
> preceding week, and facilitate thinking about core metrics in general.
>
> We will iterate on the presentation (e.g. to better take seasonality into
> account, in particular including year-over-year comparisons) and eventually
> want to create dashboards for those which are not already available in that
> form already. Feedback and discussion welcome.
>
> (All numbers below are averages for September 14-20, 2015 unless otherwise
> noted.)
>
> Pageviews:
>
> Total: 523 million/day
>
> Context (April 2015-September 2015):
>
> Pageviews were down 4.3% from last week, a somewhat noticeable drop (for a
> more dramatized view, see the Vital Signs dashboard
> ).
>
> Desktop: 58.1%
>
> Mobile web: 40.7%
>
> Apps: 1.2%
>
>
> Global North ratio: 77.4% of total pageviews
>
> Context (April 2015-September 2015):
>
>
> Unique app users
>
> Android: 1.303 million /day
>
> Context (January 2015-September 2015):
>
> A slight rise in the last two weeks, but we’re not seeing a clear effect
> of the recent media promotion for the Android app (blog post
> 
> on September 10, media coverage
> 
> on September 10, 11 and 13) - compare the bump in April around the time
> when the app was featured in the Play store and the media promotion for the
> iOS app happened (with much wider media coverage
> 
> ).
>
>
> iOS: 319k / day
>
> Context (January 2015-September 2015):
>
> No news here.
>
> New app installations
>
> Android: 44,066/day (installs per device, from Google Play, September
> 14-19)
>
> Context (Aug 21, 2015 - Sep 21, 2015):
>
> One is tempted to see a bit of a bump after the start of the media
> promotion on September 10 (concretely, average daily installs in the time
> from September 10-19 were 2.5% higher than in the time from August
> 21-September 9), but in the end we can’t really be certain whether it had
> an effect. (Compare again very visible peak in April in the year-over-year
> graph
> 
> I posted last week.)
>
> The drop on Sunday September 20 seems to be a problem with Google Play’s
> statistics (several other metrics like uninstall numbers show a similar
> drop) and not something we need to worry about; I left it out from the
> average above as an outlier.
>
>
> iOS: 4,839/day (download numbers from App Annie)
>
> Context (September 2014-September 2015):
>
>
> 
>
> For reference, the queries and source links used are listed below (access
> is needed for each). Most of the above charts have been updated on
> Commons, too
> 
> .
>
> hive (wmf)> SELECT SUM(view_count)/700 AS avg_daily_views_millions
> FROM wmf.projectview_hourly WHERE agent_type = 'user' AND
> CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")) BETWEEN "2015-09-14"
> AND "2015-09-20";
>
> hive (wmf)> SELECT year, month, day,
> CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")) as date,
> sum(IF(access_method <> 'desktop', view_count, null)) AS mobileviews,
> SUM(view_count) AS allviews FROM wmf.projectview_hourly WHERE year=2015 AND
> agent_type = 'user' GROUP BY year, month, day ORDER BY year, month, day
> LIMIT 1000;
>
> hive (wmf)> SELECT access_method, SUM(view_count)/7 FROM
> wmf.projectview_hourly WHERE agent_type = 'user' 

Re: [WikimediaMobile] Readership metrics for the week until September 13, 2015

[Jon Katz]

Thanks, Tilman!  This is a great start.

Oliver, thank you for your offer of support! For now, we are still in an
early 'agile' stage of  prioritizing features based on stakeholder's
feedback (like the one Pine raised).  I think dashboard is something we
will consider when we are further down the road on this.


On Thu, Sep 17, 2015 at 12:57 PM, Oliver Keyes  wrote:

> Are there going to be regularly updated dashboards for these KPIs? The
> Discovery team is happy to lend you some support in getting a platform set
> up, moving forward.
>
> On 17 September 2015 at 15:55, Pine W  wrote:
>
>> Thanks Tilman. Is it possible for to get ENWP-only stats for August 2015?
>> The last data for ENWP pageviews on stats.wikimedia.org is from July. A
>> breakdown of ENWP stats into mobile and desktop would also be helpful.
>>
>> Pine
>>
>>
>> On Thu, Sep 17, 2015 at 12:44 PM, Tilman Bayer 
>> wrote:
>>
>>> Hi all,
>>>
>>> with this email we are starting a weekly look at our most important
>>> readership metrics.
>>>
>>> The main purpose is to raise awareness about how these are developing,
>>> call out the impact of any unusual events in the preceding week (e.g. the
>>> media promotion for the Android app this time) and facilitate thinking
>>> about core metrics in general.
>>>
>>> We will iterate on the presentation (e.g. to better take seasonality
>>> into account, in particular including year-over-year comparisons) and
>>> eventually want to create dashboards for those which are not already
>>> available in that form already. Feedback and discussion welcome.
>>>
>>> (All numbers below are averages for September 7-13, 2015 unless
>>> otherwise noted.)
>>>
>>> Pageviews:
>>>
>>> Total: 546 million/day
>>>
>>> Context (April 2015-September 2015):
>>>
>>> [image: Wikimedia daily pageviews, all vs. mobile (April 2015-).png]
>>>
>>> After the drop in June, which by now looks not merely seasonal but
>>> likely to be at least partially connected to the rollout of HTTPS-only
>>> access begun on June 12, overall pageviews are slightly rising again
>>> recently. (Notably, the recent drop
>>>  in comScore’s
>>> numbers - also in their pageview estimates for Wikimedia sites, not
>>> reproduced in that report card - is not consistent with our own traffic
>>> data; these discrepancies are being looked into.)
>>>
>>> Desktop: 58.8%
>>>
>>> Mobile web: 39.9%
>>>
>>> Apps: 1.2%
>>>
>>>
>>> Global North ratio: 77.5% of total pageviews
>>>
>>> Context (April 2015-September 2015):
>>>
>>> [image: Wikimedia pageviews, Global South vs. Global North (April
>>> 2015-).png]
>>>
>>>
>>> Unique app users
>>>
>>> Android: 1.136 million /day
>>>
>>> Context (January 2015-September 2015):
>>>
>>> While this number is slightly higher than in the preceding week, there’s
>>> no noticeable effect visible yet from the media promotion for the Android
>>> app (blog post
>>> 
>>> on September 10, media coverage
>>> 
>>> on September 10, 11 and 13).
>>>
>>>
>>> iOS: 290k / day
>>>
>>>
>>> Context (January 2015-September 2015):
>>>
>>> New app installations
>>>
>>> Android: 40,168/day (Daily installs per device, from Google Play,
>>> September 7-11)
>>>
>>> Context (September 2014-September 2015):
>>>
>>> Unfortunately, the stats function of the Google Play is having issues
>>> currently and data for recent days has been delayed. (They “expect to
>>> resolve the issue shortly”, but the September 11 only became available this
>>> morning and I’m sending this report out now, a fuller assessment of the
>>> impact of the media campaign will need to wait.) The first two days after
>>> the blog post went out on September 10 did not yet show a marked increase:
>>>
>>> 20150911
>>>
>>> 40648
>>>
>>> 20150910
>>>
>>> 39862
>>>
>>> 20150909
>>>
>>> 39927
>>>
>>> 20150908
>>>
>>> 39981
>>>
>>> 20150907
>>>
>>> 40420
>>>
>>>
>>> iOS: 5,262/day (download numbers from App Annie)
>>>
>>> Context (September 2014-September 2015):
>>>
>>> We seem to have a slight upwards trend in recent weeks, but it’s still
>>> way below the download rate a year ago.
>>>
>>> 
>>>
>>> For reference, the queries and source links used are listed below
>>> (access is needed for each). I’ll also see to upload charts to Commons.
>>>
>>> hive (wmf)> SELECT SUM(view_count)/700 AS avg_daily_views_millions
>>> FROM wmf.projectview_hourly WHERE agent_type = 'user' AND
>>> CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")) BETWEEN "2015-09-07"
>>> AND "2015-09-13";
>>>
>>> hive (wmf)> SELECT year, month, day,
>>> CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")) as date,
>>> sum(IF(access_method <> 'desktop', view_count, null)) AS mobileviews,
>>> SUM(view_count) AS allviews FROM wmf.projectview_hourly 

Re: [WikimediaMobile] What people think about Wikidata descriptions in search on mobile web beta, and a question about arbitrary access of Wikidata data

[Jon Katz]

This is a really interesting discussion and it seems that there is
near-consensus that an automated description for entities without a manual
description is not a bad idea, particularly if they are kept in a separate
field.  Speak now if you feel that is not correct.

To S's suggestion: what steps do we need to take to put autodesc into
wiki's?

   - establish consensus with stakeholders outside this thread?
   - create new field?
   - rule out/protect against edge cases (are their length limits, for
   instance)
   - ways to edit (explaining to a user how they can edit or override is
   going to be important)


Who should own it and create an epic to track?  Wikidata, Search,
Reading?

On Fri, Aug 21, 2015 at 10:27 AM, Monte Hurd mh...@wikimedia.org wrote:

 This is why the automatic description cache and the manual description
 need to be kept separate; just pasting the autodesc into the manual
 description field would mean it could never be updated automatically. That
 would be very bad indeed.


 +1000 Exactly! I was operating under the assumption we were talking
 about the existing description field. Separate auto and manual
 description fields completely avoids *all* of the issues/concerns I raised
 :)

 On Thu, Aug 20, 2015 at 2:48 AM, Magnus Manske 
 magnusman...@googlemail.com wrote:

 So it turns out that ValterVBot alone has created over 1.8 MILLION
 manual descriptions. And there are other bots that do this. We already
 HAVE automatic descriptions, we just store them in the manual field.

 The worst of both worlds.

 On Thu, Aug 20, 2015 at 9:24 AM Magnus Manske 
 magnusman...@googlemail.com wrote:

 On Thu, Aug 20, 2015 at 1:43 AM Monte Hurd mh...@wikimedia.org wrote:

 True about algorithms never being finished, but aren't we essentially
 stuck with the first run output, unless I misunderstand how you envision
 this working?

 (assuming you don't want to over-write non-blank descriptions the next
 time you improve and re-run the process)


 Of course we're not stuck with the initial automatic descriptions!
 Whatever gave you that idea? Ideally, each description would be computed
 on-the-fly, but that won't scale; output needs to be cached, and
 invalidated when necessary.

 Possible reasons for cache invalidation:
 * The item statements have changed
 * Items referenced in the description (e.g. country for nationality)
 have changed
 * The algorithm has been improved
 * After cache reached a certain age, just to make sure

 This is why the automatic description cache and the manual description
 need to be kept separate; just pasting the autodesc into the manual
 description field would mean it could never be updated automatically. That
 would be very bad indeed.



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


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

[WikimediaMobile] event logging bloat

[Jon Katz]

Hi folks,
Back in January, the size of MobileWebClickTracking had gotten to be over
200 gb, making it so slow as to be unusable.  As a result, we split up the
into 3 separate tables.

 However, it seems that 90% of the clicks are coming from the article
table (or adding search created bloat) and
MobileWebUIClickTracking_10742159 is now approaching 300gb.  Mostly this is
due to search. I would encourage further sampling, but that would mean that
beta data would be lost.  Perhaps we can split it into separate beta/stable
tables and then sample stable? Any other ideas?

Phab ticket here:
https://phabricator.wikimedia.org/T108723

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

Re: [WikimediaMobile] [Wikimedia-search] Fwd: Morelike suggestions - the results are in!

[Jon Katz]

I'm late to this, but great news!

I just want to commend those involved for a great example of
cross-pollination between the web team and the app team.  This is all the
more impressive, given that the backend service was designed for A by the
growth team(?), web is using it for B, and the app is using it for C.
Communication!
-J

On Wed, Jul 29, 2015 at 2:23 PM, Dmitry Brant dbr...@wikimedia.org wrote:

 Will surely take note for next time. Thanks!
 Now that we've got the results from this test, we will soon update the app
 to use *only* morelike suggestions, which means you'll be getting twice as
 many morelike queries from the app as before. (We'll let you know when
 that's released)


 On Wed, Jul 29, 2015 at 4:17 PM, Oliver Keyes oke...@wikimedia.org
 wrote:

 This is fantastic work to see!

 For future work around this stuff, can I ask that you keep us in the
 loop? When you build a feature like this, users get more things - and
 search gets more queries, some that succeed and some but fail. But for
 this email at the tail-end of the test we wouldn't know this was
 happening, and it has the potential to mess with some of our core
 KPIs.

 On 29 July 2015 at 16:01, Dmitry Brant dbr...@wikimedia.org wrote:
  moving to mobile-l, and cc Search  Discovery.
 
  -- Forwarded message --
  From: Dmitry Brant dbr...@wikimedia.org
  Date: Wed, Jul 29, 2015 at 3:38 PM
  Subject: Morelike suggestions - the results are in!
  To: Internal communication for WMF Reading team
  reading-...@lists.wikimedia.org
 
 
  Hi all,
 
  For the last few weeks, we've had an A/B test in the Android app where
 we
  measure user engagement with the read more suggestions that we show
 at the
  bottom of each article. We display three suggestions for further
 reading,
  based on either (A) a plain full-text search query based on the title
 of the
  current article, or (B) a query using the morelike feature in
  CirrusSearch.
 
  And the winner is... (perhaps not entirely surprisingly) morelike!
 Users
  who saw suggestions based on morelike were over 20% more likely to
 click
  on one of the suggestions.
 
  Here's a quick analysis and chart of the data from the last 10 days:
 
 
 https://docs.google.com/spreadsheets/d/1BFsrAcPgexQyNVemmJ3k3IX5rtPvJ_5vdYOyGgS5R6Y/edit?usp=sharing
 
 
  -Dmitry
 
 
 
  ___
  Wikimedia-search mailing list
  wikimedia-sea...@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/wikimedia-search
 



 --
 Oliver Keyes
 Research Analyst
 Wikimedia Foundation

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



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


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

Re: [WikimediaMobile] Android app bug report template

[Jon Katz]

awesome, Bernd!

On Mon, Jul 6, 2015 at 10:07 AM, Bernd Sitzmann be...@wikimedia.org wrote:

 https://phabricator.wikimedia.org/T104086 is a bug report template for
 Android issues.
 The easiest way to file a new bug is to go there and click on the link to
 file a pre-populated Phab ticket. Most of the time the regular one is
 what you need. If you fill out bugs coming from OTRS or crash reports then
 use the second one.

 You can also find this template in the last column of our Android
 workboard[1].

 Cheers,
 Bernd

 [1] https://phabricator.wikimedia.org/tag/wikipedia-android-app/



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


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

Re: [WikimediaMobile] Task/bug naming conventions

[Jon Katz]

Good call, Gergo, and for calling out crap when you see it.  I know I am to
blame on a lot of these (including the above example).  I think the
language solution you described is pretty good.

restating suggested rules for those who don't read prose:

   - bugs--explain bad state in present tense (and desired state in
   description if nec). Users screen goes blank
   - enhancement--explain desired state as imperative Make it so users
   can.. or Users should be able to...

I think we could go a step further and call out bugs with the prefix bug:
for more clarity.

-J


On Mon, Jun 8, 2015 at 10:38 AM, Jeff Hobson jhob...@wikimedia.org wrote:

 +1, also any bugs should have clear repro steps in description and wanted
 features should have a clear UX path/outlined steps.

 Thanks,

 Jeff Hobson
 On Jun 8, 2015 1:33 PM, Gergo Tisza gti...@wikimedia.org wrote:

 Hi all,

 I would like to recommend a naming convention that clearly differentiates
 between existing and wanted behavior. This is something that has been
 confusing for me for a while - bugs and tasks are both in the indicative so
 I often have trouble deciding whether a ticket describes a situation that
 exists but should not or one that does not exist but should.

 Random example from current sprint board: Anon users can access public
 view from main menu with the associated description being When anonymous
 and I click collections I am taken to the public view. Does this mean that
 anonymous users should not be able to access the public view but somehow
 they can, or is this the description of a wanted feature? I can figure it
 out by digging up context, of course, but that takes time; ideally, this
 should be clear from just the task title (which I might be seeing in a list
 or on a workboard).

 I think it would be clearer if the title of the task would always
 reflected the situation at the time of creating the task, and titles
 describing a wanted but not currently existing state were phrased as
 imperatives. So if anons can see the public view right now and that's a bug
 the title would say anons can access public view; if they cannot access
 it currently but that's a feature we want, the title would say anons
 should be able to access public view or make anons able to access public
 view.

 Thoughts?

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


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


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

Re: [WikimediaMobile] [reading-wmf] Wikipedia article previews in Kindle app

[Jon Katz]

+ Kouroush

A summary of ideas:

*WP as destination:*
-Sister projects swipable from cards
-WMF owned OS integration/browser add-ons

*WP as platform:*
-API for 'cards' on topics/JS library
-Make sure API changes aren't breaking experience for: apple, google,
amazon?
-Help kindle optimize their calls
-Key partner list...do we have this for major integrations?

These are great ideas, and I don't want to lose them.
What should go on the brainstorming etherboard for Q1
https://etherpad.wikimedia.org/p/Q1_Readership_Brainstorm and what should
go elsewhere (and how do we make sure elsewhere isn't purgatory).

-J

On Mon, Jun 8, 2015 at 11:34 AM, Gergo Tisza gti...@wikimedia.org wrote:

 On Mon, Jun 8, 2015 at 1:04 AM, S Page sp...@wikimedia.org wrote:

 Maybe WMF should offer its own browser- or OS-level integration, pushing
 the reading experience way beyond our sites.
 https://en.wikipedia.org/wiki/Wikipedia:Tools/Browser_tools lists
 various browser addons, such as Lookup companion for Wiki
 https://chrome.google.com/webstore/detail/lookup-companion-for-wiki/dhgpkiiipkgmckicafkhcihkcldbdeej?hl=en
 that do this. Meanwhile
 https://en.wikipedia.org/wiki/Wikipedia:Tools#Searching has Download
 1-Click Answers Wikipedia Edition for Windows (beta) and then Alt-Click on
 any word in any program on your screen for instant, accurate facts. Who
 knew?!, makes me want to bust out Windows 2000 :)


 A WMF-maintained self-contained javascript library to fetch Wikipedia
 summaries / Wikidata descriptions / Wikitionary translations (and maybe
 even Commons images) for a given string and display them in a configurable
 popup window would be awesome. That could then be used as a bookmarklet, in
 browser extensions (most of those are written in JS so they just need a
 trivial wrapper around the library), or in web pages as a functionality
 provided by the site owner.

 ___
 reading-wmf mailing list
 reading-...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/reading-wmf


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

[WikimediaMobile] Gather update

[Jon Katz]

Hi People Interested in Gather,


Given the reorg and the traffic being driven to beta, we need to revisit
Gather's Q4 goals:

TLDR: Continue working on gather to finish MVP features (end of the month,
max), not pushing to stable unless we see 2x the number of logged-in edits
on beta (or 10x current state).


Before the serious stuff:


Top 5 best collections since Monday:

https://en.m.wikipedia.org/wiki/Special:Gather/by/Johnrenfro

https://en.m.wikipedia.org/wiki/Special:Gather/id/3454/Philadelphia_watch

https://en.m.wikipedia.org/wiki/Special:Gather/id/3401/engineering

https://en.m.wikipedia.org/wiki/Special:Gather/id/3532/Mental_Health

https://en.m.wikipedia.org/wiki/Special:Gather/id/3132/Libertarianismo


Okay, now the goals. Please feel free to comment in email or in this google
doc
https://docs.google.com/a/wikimedia.org/document/d/1DK1pa3PEpIbiON0Bj6BrhGAnePqZcKSmqTW1z6sTKvU/edit?usp=sharing


Thanks,


Jon



Given the reorg and an improvement made to beta, we need to revisit
Gather's goals


Pushing to Stable

Given that we can now test Gather numbers in beta, the original goal of
launching on stable to test adoption is no longer valid.  It is expensive
in terms of future maintenance and commitments to launch features to
stable, so we only want to do so after we have proven success, if possible.



Target numbers

Originally, the benchmarks for success on stable that were agreed on were
low (10k creators a month on stable, and 1k shares).  Given the current
beta numbers, it looks like we will blow the first number out of the
water.  Share has been deprioritized given current usage patterns.
However, given that we now have 4 engineers in charge of the entire web,
the standards for what we work on have to be more rigorous.  We cannot
allocate multiple engineers to an experimental product unless it shows
promise of impacting greater numbers



   1. Goal
  1.

  New Goal:
  1.

 Round out Gather hypothesis (criteria below)
 2.

 By end of June know whether or not we want to push Gather to stable



   1. Next Eng+PM Steps (to round out hypothesis)
  1.

  Improve onboarding (a few tasks)
  2.

  Surface collections publicly (this is a big missing feature)
  3.

  Qualitative and quantitative research

  2. Criteria for passing to stable:

We don’t have a great way to measure success of Gather based on usage by a
proportion of users or logged in users.  However, we can compare to
something similar like edits.  In terms of pure value to WP, we can
consider a collection to be like a low-value edit.



   -

   There are 2x ‘good’ collections made as there are total logged-in
   edits/month
   -

  in May there were 2,180 edits by logged in users (2,694 logged out).
  -

  At current rates this suggests ~4,500 collections per month is our
  target.
  -

  ‘good’ here, means 1 collection--it’s not a perfect definition, but
  it’s a strong proxy.
  -

  Our current rate of ‘good’ collections is roughly 250 a month, so we
  will need to increase the number by almost 20x.
  -

  It might be worth exploring % of those 2,180 edits that are reverted
  and adjusting down accordingly

 OR



   -

   Views of collections or where collection is the referrer  .5% of total
   pageviews
   -

  Currently, the views of collections are minimal.
  -

  If very few people create collections, but they drive a significant
  boost in page views, say .5% of total PVs (not an end goal, but also not
  bad for an MVP introducing a new use case), then the feature is a success.




   1. What if we don’t pass to stable:

Lets burn that bridge when we get to it :) . Seriously though, until we get
some qualitative data back from our readers, we will not be able to make
important calls on the feature as is. There are a few great alternatives I
can think of right off the bat:

   -

   Keep code in beta and work on Gather opportunistically or as qualitative
   data dictates
   -

  One example might be to make collections private by default and
  launch as bookmarker for readers (primary current use-case)
  -

   Promote as beta feature on desktop
   -

   Use codebase as start of multiple watchlists (some good work started
   here by JRobson)
   -

   Codebase is fairly generic list table that has some basic and
   interesting features built in that could be used for a number of other ends




   1. Validation and why we choose this criteria:


Qualitative questions to answer:

Why aren't more people using Gather? (correctly)

Why aren't people returning to use Gather more


Success metric questions to answer (that we can’t already):

What % of logged in users use Gather

What % of users who visit  1 page use Gather




What is our denominator

Status

Measure logins and signup funnel directed from Gather, what is % success
rate?

This is not instrumented

Measure % of sessions 

Re: [WikimediaMobile] [Wikitech-l] [reading-wmf] Wikigrok code no longer being worked on

[Jon Katz]

I'm inclined to agree with Matt.  In fact (and to answer Oliver's
question), the team is already considering the next slew of
micro-contribution projects.

I think it is too early to say which projects will be next, but some ideas
include: choosing lead images, editing wikidata descriptions, and refining
categorization of topics.

Joaquin, I agree that lessons learned would be helpful.  As someone who
came to the project at the very end, I don't feel entitled to point out
things that should have been done differently.  As a member of the team
that made the decision to pause development, however, I would be happy to
help establish criteria that projects need to meet (as a minimum) in order
to see continued effort.  Given my limited bandwidth, this is not something
I can promise anytime soon and I encourage others to take a first stab.

-J


On Tue, Jun 2, 2015 at 6:23 PM, Matthew Flaschen mflasc...@wikimedia.org
wrote:

 On 06/02/2015 06:00 AM, Joaquin Oltra Hernandez wrote:

 Now there's a lot of skepticism towards the idea in any of its forms :(


 I still think micro-contributions are an important future direction
 (whether or not WikiGrok is re-activated).

 Given how successful the metrics were from WikiGrok, it's hard to see why
 there should be skepticism about the idea of micro-contributions.

 Matt Flaschen



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

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

[WikimediaMobile] Wikigrok code no longer being worked on

[Jon Katz]

Hi,

*TLDR:* Wikigrok proved that readers are interested in and capable of
making casual, mobile contributions to Wikipedia. We are putting continued
development of the 'Wikigrok' casual contribution feature on hold until we
have a plan for optimally harnessing this interest/capability.

*Background*
Given the growth of mobile traffic on wikipedia and the challenges inherent
to traditional editing on a mobile device, Wikigrok was proposed as a way
to test if regular wikipedia readers would be interested in making smaller,
more casual contributions to wikimedia projects while reading Wikipedia on
a mobile device.

*Results*
By early 2015, the results were in: readers were relatively interested in
engaging with the feature[1].  Some oft-quoted comparisons include:

   - 3x the number of unique responders as mobile editors during test
   period (4.5K editors, 12.3K WikiGrokkers), even with WG on sample of
   articles  users
   - 1.5x better clickthrough than 2014 Fundraising full-screen mobile
   banner

(I actually do not have references for these, as they are borrowed quotes)
Furthermore, we found that the quality of responses was rather high [2,3].

*Future*
The original thought was to use these responses to fill in gaps in Wikidata
and our initial test results (2 weeks worth) were successfully ported over
in late April [4]. However, in order to production-ize the system, we would
have to:

   1. scale and develop queries against the new wikidata query service
   2. create an article parser to identify potential multiple choice
   answers for each question
   3. create a system for attributing aggregated results to the specific
   contributors (per Wikidata bot request discussion[5])

None of these are unsurpassable, but we have learned a great deal and, at
this stage, we believe that further effort should be devoted to evaluating
areas of need and fit before we commit additional efforts to specifically
porting information into Wikidata.

Please feel free to reach out if you have any questions or concerns about
this decision.
Best,

Jon

[1] https://meta.wikimedia.org/wiki/Research:WikiGrok/Test2
[2] Quality of responses, version A:
https://www.wikidata.org/wiki/File:All_Campagins,_Scatterplot,_version_(a).pdf
[3] Quality of responses, version B:
https://www.wikidata.org/wiki/File:All_Campaigns,_Scatterplot,_version_(b).pdf
[4] *https://www.wikidata.org/wiki/Special:Contributions/WikiGrok?limit=500
https://www.wikidata.org/wiki/Special:Contributions/WikiGrok?limit=500*
[5]
https://www.wikidata.org/wiki/Wikidata:Requests_for_permissions/Bot/WikiGrok
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Wikigrok code no longer being worked on

[Jon Katz]

Hi Oliver,
Thanks for sharing your disappointment.  I do not think you are alone in
wanting to see wikigrok continue and grow.  I would clarify that the
'success rates' you allude to were for  reader engagement and accuracy, not
in actually improving our projects by filling in important gaps in
wikidata.  A great deal of work would be required to build out in order for
this project to have a scalable impact on wikidata.

I am not saying that casual contributions are going away, simply that we
are going to recognize our resource limitations and evaluate opportunities
for them based on highest return-on-investment. We currently have 5
developers working on readership for the entire web (due to some temporary
leaves) and there might be smaller wins using casual contributions that
work towards our end goal, but don't require the heavy upfront investment.
This doesn't mean we don't take on big thorny problems, just that we take a
step back and see if there are ways to subdivide them into smaller projects
along the way.

Best,

Jon

[1]
https://www.wikidata.org/wiki/Wikidata:Requests_for_permissions/Bot/WikiGrok

On Mon, Jun 1, 2015 at 12:05 PM, Oliver Keyes oke...@wikimedia.org wrote:

 I'm personally incredibly disappointed; this was the most successful
 intervention I'd seen anyone try in a long while, if ever, and the
 results blow me away. My question would be what interventions with
 similarly high success rates are going to be worked on instead? - I
 assume that we're not working on them because we can achieve the same
 outcome through easier-to-implement interventions. I would be
 interested to hear what those interventions are.

 On 1 June 2015 at 14:57, Jon Katz jk...@wikimedia.org wrote:
  Hi,
 
  TLDR: Wikigrok proved that readers are interested in and capable of
 making
  casual, mobile contributions to Wikipedia. We are putting continued
  development of the 'Wikigrok' casual contribution feature on hold until
 we
  have a plan for optimally harnessing this interest/capability.
 
  Background
  Given the growth of mobile traffic on wikipedia and the challenges
 inherent
  to traditional editing on a mobile device, Wikigrok was proposed as a
 way to
  test if regular wikipedia readers would be interested in making smaller,
  more casual contributions to wikimedia projects while reading Wikipedia
 on a
  mobile device.
 
  Results
  By early 2015, the results were in: readers were relatively interested in
  engaging with the feature[1].  Some oft-quoted comparisons include:
 
  3x the number of unique responders as mobile editors during test period
  (4.5K editors, 12.3K WikiGrokkers), even with WG on sample of articles 
  users
  1.5x better clickthrough than 2014 Fundraising full-screen mobile banner
 
  (I actually do not have references for these, as they are borrowed
 quotes)
  Furthermore, we found that the quality of responses was rather high
 [2,3].
 
  Future
  The original thought was to use these responses to fill in gaps in
 Wikidata
  and our initial test results (2 weeks worth) were successfully ported
 over
  in late April [4]. However, in order to production-ize the system, we
 would
  have to:
 
  scale and develop queries against the new wikidata query service
  create an article parser to identify potential multiple choice answers
 for
  each question
  create a system for attributing aggregated results to the specific
  contributors (per Wikidata bot request discussion[5])
 
  None of these are unsurpassable, but we have learned a great deal and, at
  this stage, we believe that further effort should be devoted to
 evaluating
  areas of need and fit before we commit additional efforts to specifically
  porting information into Wikidata.
 
  Please feel free to reach out if you have any questions or concerns about
  this decision.
  Best,
 
  Jon
 
  [1] https://meta.wikimedia.org/wiki/Research:WikiGrok/Test2
  [2] Quality of responses, version A:
 
 https://www.wikidata.org/wiki/File:All_Campagins,_Scatterplot,_version_(a).pdf
  [3] Quality of responses, version B:
 
 https://www.wikidata.org/wiki/File:All_Campaigns,_Scatterplot,_version_(b).pdf
  [4]
 https://www.wikidata.org/wiki/Special:Contributions/WikiGrok?limit=500
  [5]
 
 https://www.wikidata.org/wiki/Wikidata:Requests_for_permissions/Bot/WikiGrok
 
 
  ___
  Mobile-l mailing list
  Mobile-l@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/mobile-l
 



 --
 Oliver Keyes
 Research Analyst
 Wikimedia Foundation

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

Re: [WikimediaMobile] [reading-wmf] Fwd: Mobile Firendly

[Jon Katz]

+external mobile and wikitech

Shoot.  I meant to send this the external list.  For those of you just
joining us, we recently got an email from google letting us know that some
of our pages are now failing the mobile-friendly test, which has an adverse
impact on our search results.  It appears that most of our pages are also
blocking style info.

Google doesn't offer much insight into penalties, but if they're sending us
the email then it is or will have some impact.  I'd like to see if we can
better understand the other side of the equation- what is cost of fixing
it?  I think Jon's questions below are the ones to start with.

-J


On Fri, May 29, 2015 at 1:35 PM, Jon Robson jrob...@wikimedia.org wrote:

 It's all in the report. We block w/ in robots.txt always have.

 There have been a bunch of changes to improve performance of the site
 overall which might have led to that. Mailing this to the public mailing
 list wikitech would give you a better idea.

 Our site /is/ mobile friendly it's just we tell google not to load styles
 from w/load.php so no need to panic.

 The question is what is the penalty of us failing this tool? Does it
 impact our google search rankings?

 Fix is trivial.. Update robots.txt but first the question is why are we
 blocking scripts and styles on that url?
 On 29 May 2015 1:17 pm, Jon Katz jk...@wikimedia.org wrote:

 Hi Readership team and broader community,
 Any changes we might have recently made to cause this warning to appear
 about googlebot not being able to access our site?
 I consider this to be a very serious issue.
 The examples below are not mobile, but same issue applies when you try an
 en.m. version of the pages.

 Best,
 Jon


 -- Forwarded message --
 From: Wes Moran wmo...@wikimedia.org
 Date: Fri, May 29, 2015 at 12:47 PM
 Subject: Mobile Firendly
 To: Jon Katz jk...@wikimedia.org
 Cc: Adam Baso ab...@wikimedia.org


 Jon,

 Google notified us of the followin...

 We recently noticed that there was a change with how you embed CSS  JS
 which results in us not being able to use the CSS  JS to recognize what
 the page looks like. That's making some of your pages fail the
 mobile-friendly-test, for example. You used to load CSS  JS from
 bits.wikimedia.org, but now they're loaded through /w/load.php?...
 directly from the Wikipedia host, where that path is blocked by robots.txt.

 You can see how we render the pages with Fetch as Google in Webmaster
 Tools / Search Console, you can also see most of that with the test-page at:

 https://www.google.com/webmasters/tools/mobile-friendly/?url=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FBusot

 Some of the pages still pass the test there (example
 https://www.google.com/webmasters/tools/mobile-friendly/?url=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FZ%25C3%25BCrich),
 but the CSS is broken there too since it's blocked. 

 Any ideas what can be causing this?

 Regards,
 Wes


 ___
 reading-wmf mailing list
 reading-...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/reading-wmf


 ___
 reading-wmf mailing list
 reading-...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/reading-wmf


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

Re: [WikimediaMobile] [reading-wmf] Fwd: Mobile Firendly

[Jon Katz]

Since Brandon's email a minute ago crossed mine in the ether and did not
make it to external lists, I am pasting it here:

On Fri, May 29, 2015 at 1:53 PM, Brandon Black bbl...@wikimedia.org wrote:
We've merged up https://gerrit.wikimedia.org/r/#/c/214705/1 to address
this, and I've purged the caches to ensure the update is fully live
already.  It should address the issue, assuming that the block on RL's
/w/load.php entry point was the only part of the problem.

On Fri, May 29, 2015 at 1:55 PM, Jon Katz jk...@wikimedia.org wrote:

 +external mobile and wikitech

 Shoot.  I meant to send this the external list.  For those of you just
 joining us, we recently got an email from google letting us know that some
 of our pages are now failing the mobile-friendly test, which has an adverse
 impact on our search results.  It appears that most of our pages are also
 blocking style info.

 Google doesn't offer much insight into penalties, but if they're sending
 us the email then it is or will have some impact.  I'd like to see if we
 can better understand the other side of the equation- what is cost of
 fixing it?  I think Jon's questions below are the ones to start with.

 -J


 On Fri, May 29, 2015 at 1:35 PM, Jon Robson jrob...@wikimedia.org wrote:

 It's all in the report. We block w/ in robots.txt always have.

 There have been a bunch of changes to improve performance of the site
 overall which might have led to that. Mailing this to the public mailing
 list wikitech would give you a better idea.

 Our site /is/ mobile friendly it's just we tell google not to load styles
 from w/load.php so no need to panic.

 The question is what is the penalty of us failing this tool? Does it
 impact our google search rankings?

 Fix is trivial.. Update robots.txt but first the question is why are we
 blocking scripts and styles on that url?
 On 29 May 2015 1:17 pm, Jon Katz jk...@wikimedia.org wrote:

 Hi Readership team and broader community,
 Any changes we might have recently made to cause this warning to appear
 about googlebot not being able to access our site?
 I consider this to be a very serious issue.
 The examples below are not mobile, but same issue applies when you try
 an en.m. version of the pages.

 Best,
 Jon


 -- Forwarded message --
 From: Wes Moran wmo...@wikimedia.org
 Date: Fri, May 29, 2015 at 12:47 PM
 Subject: Mobile Firendly
 To: Jon Katz jk...@wikimedia.org
 Cc: Adam Baso ab...@wikimedia.org


 Jon,

 Google notified us of the followin...

 We recently noticed that there was a change with how you embed CSS  JS
 which results in us not being able to use the CSS  JS to recognize what
 the page looks like. That's making some of your pages fail the
 mobile-friendly-test, for example. You used to load CSS  JS from
 bits.wikimedia.org, but now they're loaded through /w/load.php?...
 directly from the Wikipedia host, where that path is blocked by robots.txt.

 You can see how we render the pages with Fetch as Google in Webmaster
 Tools / Search Console, you can also see most of that with the test-page at:

 https://www.google.com/webmasters/tools/mobile-friendly/?url=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FBusot

 Some of the pages still pass the test there (example
 https://www.google.com/webmasters/tools/mobile-friendly/?url=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FZ%25C3%25BCrich),
 but the CSS is broken there too since it's blocked. 

 Any ideas what can be causing this?

 Regards,
 Wes


 ___
 reading-wmf mailing list
 reading-...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/reading-wmf


 ___
 reading-wmf mailing list
 reading-...@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/reading-wmf



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

Re: [WikimediaMobile] Gather sprint Help! kicked off

[Jon Katz]

Thanks, Jon!

For those of you who are wondering, the name of our sprint: Help! is a
reference to the Beatles' album from 1965 (featuring such classic hits as
Help!, Ticket to Ride and Yesterday).  It is definitely not a
desperate plea from the ghost of a long forgotten phabricator task or the
mad engineer Jon R may or may not have locked in his attic.

On Mon, May 11, 2015 at 2:29 PM, Jon Robson jrob...@wikimedia.org wrote:

 Members of the readership team who are working on the Gather extension
 kicked off sprint Help! [1] today after completing sprint Greatest hits
 [2] with 17 story points out of the 30 we committed to. We had a few
 disruptions, e.g. a reorg just happened :-)!, so we're not too concerned
 about not meeting our target.

 Sprint Greatest hits mostly saw us polishing existing features, discussing
 some architecture changes and improving our infrastructure. Tangibly it
 resulted in seeing our beta opt ins increase jump from 2K to 40K a day [3]
 but we experienced a few hiccups! We are also now showing a create
 collection button at the bottom of the collections page.

 This sprint we've committed to 26 story points, a little less than the
 normal 30, mostly in anticipation of disruption due to the Lyon hackathon.
 We'll be exploring an auto-moderation system, more infrastructure changes,
 and improving our onboarding workflow to try and minimise the amount of 1
 item collections we are seeing.

 [1] https://phabricator.wikimedia.org/tag/gather_sprint_help!/
 [2] https://phabricator.wikimedia.org/tag/gather_sprint_greatest_hits/
 [3] http://mobile-reportcard.wmflabs.org/#other-graphs-tab

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


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

Re: [WikimediaMobile] Fwd: Content missing from mobile apps and mobile web

[Jon Katz]

Hi Pine,
I'm the PM for mobile web and I am listening :) I don't yet understand
fully, but want to understand better.  I will see if Dan Garry can get me
up to speed, but can I follow up with you if I have additional questions?

Thanks,

Jon


On Tue, Mar 31, 2015 at 9:07 PM, Pine W wiki.p...@gmail.com wrote:

 Ok, thanks all for the replies. Does the mobile web team participate on
 this email list, or is this list only for mobile apps? It seems like I see
 lots of mobile apps people here but no one that I can quickly identify
 on-list as representing mobile web.

 Pine

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


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

Re: [WikimediaMobile] Gather - owner

[Jon Katz]

Hi Amir,
I want to help on this, but am not sure where this shows up. Can you refer
us to where in the interface owner appears?
Thanks,
J

On Sun, Mar 29, 2015 at 2:50 PM, Amir E. Aharoni 
amir.ahar...@mail.huji.ac.il wrote:

 Hi,

 I am translating Gather, and I feel very uncomfortable about the term
 Owner.

 It's challenging to translate, because in the languages I care about -
 Hebrew and Russian - it requires gender. Now gender can be added without
 too much technical effort, but there's still the general feeling of
 discomfort - owner is a strong word in the Wikimedia world, which should
 usually be avoided without a good reason.

 Was this word chosen intentionally, to show that lists are, in fact,
 owned, and privately curated?

 Maybe it could be changed to something like maintainer, curator or
 something else? Or simply User?

 --
 Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
 http://aharoni.wordpress.com
 ‪“We're living in pieces,
 I want to live in peace.” – T. Moore‬

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


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