April 2015 - Mobile-l - lists.wikimedia.org

[Apps] Stripping content inside brackets from the first sentence of articles
by Dan Garry 07 Oct '19

07 Oct '19

Hi everyone, *tl;dr: We'll be stripping all content contained inside brackets from the first sentence of articles in the Wikipedia app.* The Mobile Apps Team is focussed on making the app a beautiful and engaging reader experience, and trying to support use cases like wanting to look something up quickly to find what it is. Unfortunately, there are several aspects of Wikipedia at present that are actively detrimental to that goal. One example of this are the lead sentences. As mentioned in the other thread on this matter <https://lists.wikimedia.org/pipermail/mobile-l/2015-March/008715.html>, lead sentences are poorly formatted and contain information that is detrimental to quickly looking up a topic. The team did a quick audit <https://docs.google.com/a/wikimedia.org/spreadsheets/d/1BJ7uDgzO8IJT0M3UM2q…> of the information available inside brackets in the first sentences, and typically it is pronunciation information which is probably better placed in the infobox rather than breaking up the first sentence. The other problem is that this information was typically inserted and previewed on a platform where space is not at a premium, and that calculation is different on mobile devices. In order to better serve the quick lookup use case, the team has reached the decision to strip anything inside brackets in the first sentence of articles in the Wikipedia app. Stripping content is not a decision to be made lightly. People took the time to write it, and that should be respected. We realise this is controversial. That said, it's the opinion of the team that the problem is pretty clear: this content is not optimised for users quickly looking things up on mobile devices at all, and will take a long time to solve through alternative means. A quicker solution is required. The screenshots below are mockups of the before and after of the change. These are not final, I just put them together quickly to illustrate what I'm talking about. - Before: http://i.imgur.com/VwKerbv.jpg - After: http://i.imgur.com/2A5PLmy.jpg If you have any questions, let me know. Thanks, Dan -- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation

13 22

WG: AW: [Wikitech-l] Anonymous editing impact on mobile
by Florian Schmidt 23 Jul '15

23 Jul '15

Fwd, forgot to press answer all :( Gesendet mit meinem HTC ----- Weitergeleitete Nachricht ----- Von: "Florian Schmidt" <florian.schmidt.welzow(a)t-online.de> An: "Aaron Halfaker" <ahalfaker(a)wikimedia.org> Betreff: AW: [WikimediaMobile] [Wikitech-l] Anonymous editing impact on mobile Datum: Do., Apr. 30, 2015 16:26 Great to read this, thanks Aaron :) Gesendet mit meinem HTC ----- Nachricht beantworten ----- Von: "Aaron Halfaker" <ahalfaker(a)wikimedia.org> An: "Wikimedia developers" <wikitech-l(a)lists.wikimedia.org>, "mobile-l" <mobile-l(a)lists.wikimedia.org> Betreff: [WikimediaMobile] [Wikitech-l] Anonymous editing impact on mobile Datum: Do., Apr. 30, 2015 01:09 Hey folks, As requested, I started a research project page to do some analysis around this. See https://meta.wikimedia.org/wiki/Research:Mobile_anonymous_apocalypse It's just a stub now. I'll have to clear a few other projects off my plate in order to pick this one up. You should expect to see updates there in 2-3 weeks. -Aaron On Wed, Apr 29, 2015 at 12:10 PM, Jon Robson <jdlrobson(a)gmail.com> wrote: > On Wed, Apr 29, 2015 at 8:19 AM, Robert Rohde <rarohde(a)gmail.com> wrote: > > > > On Tue, Apr 28, 2015 at 10:31 PM, Jon Robson <jrobson(a)wikimedia.org> > wrote: > > > > > <snip> > > > > Any community members interested in helping out here? I'm very sad the > > > increase in errors wasn't picked up sooner... :-/ > > > > > > > What does event_action = 'error' actually mean? > > > > If the action is stopped by the AbuseFilter is that counted as an > "error"? > > It means at some point during the editing workflow the user hit an > error that stopped them from finishing their edit. > We do capture AbuseFilter hits in this process (but with some of these > errors you can recover and complete the edit. > > We also store the error associated, although a quick scan shows this > is currently not very helpful. > > In theory 'http' error should only happen when a user cannot get an > edit token - I've updated the bug for those interested. > > > > > -Robert > > _______________________________________________ > > Wikitech-l mailing list > > Wikitech-l(a)lists.wikimedia.org > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > > > > -- > Jon Robson > * http://jonrobson.me.uk > * https://www.facebook.com/jonrobson > * @rakugojona > > _______________________________________________ > Wikitech-l mailing list > Wikitech-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l >

2 1

Skynet is winning the battle on IRC
by Joaquin Oltra Hernandez 04 May '15

04 May '15

Hi! I've been feeling that the signal to noise ratio on #wikimedia-mobile since the addition of wikibugs and our new apps engineers (more grrrit-wm spam) is turning to be 0 (that is, no signal because of too much noise). It is really difficult to talk about anything when somebody else is working (and that is what we do, so...). I would like to propose moving the machines to a different channel, maybe a couple of them ( #wikimedia-mobile-web-bots & #wikimedia-mobile-apps-bots for example ) so that they continue to be useful but in a different channel, and so that we can read again the chats with just the conversations. What do you think? Cheers.

13 18

API Phabricator cards, list threads, other
by Adam Baso 01 May '15

01 May '15

Hi there team - We're interested in pulling together API needs from mobile web and apps. I know there have been various Bugzilla/Phabricator tasks, public list threads, and so on (and some projects, like the one Bernd has been speerheading). That said, would people please add links at the following page to help centralize this information? https://www.mediawiki.org/wiki/Wikimedia_Reading/Mobile_needs_from_MediaWik… The purpose of this is to start planning ahead for coordination especially with Brad Jorsch - Mr. API! - on the Reading team. -Adam

9 9

Gather 1.26wmf3 deployment
by Rob Moen 30 Apr '15

30 Apr '15

Hello Gatherlings and other folks who may or may not be interested, Today Gather's 1.26wmf3 deployment branch was updated to master and deployed to wikis running 1.26wmf3. Tomorrow en.wiki is riding the deployment train and all wikis will be updated to wmf3 [1] So our latest changes will be reflected then. The reason we cannot deploy master to wmf2 today is because of the API change [2]. This change is not backwards compatible, therefore cherry-picking it to wmf2 would in no doubt have had unforeseen complications with other extensions / core components on wmf2 deployment branch. Core changes like this with massive deprecations / non-backwards compatibility while rare, is a battle we face when doing weekly updates. 1: https://www.mediawiki.org/wiki/MediaWiki_1.26/Roadmap 2: https://gerrit.wikimedia.org/r/#/c/182858 -- Rob Moen Wikimedia Foundation rmoen(a)wikimedia.org

3 4

Good API Lists
by Adam Baso 30 Apr '15

30 Apr '15

Hi, realized I should share this on mobile-l. Just wanted to quickly recommend that engineers and others with an interest sign up for the following lists: https://lists.wikimedia.org/mailman/listinfo/mediawiki-api https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce These are pretty technical lists for people interested in working with the MediaWiki hosted APIs. I'm excited that engineers will be working even more closely together on the APIs and service integration to support the best possible reading experiences. -Adam

2 1

Re: [WikimediaMobile] [Wikitech-l] Anonymous editing impact on mobile
by Aaron Halfaker 30 Apr '15

30 Apr '15

Hey folks, As requested, I started a research project page to do some analysis around this. See https://meta.wikimedia.org/wiki/Research:Mobile_anonymous_apocalypse It's just a stub now. I'll have to clear a few other projects off my plate in order to pick this one up. You should expect to see updates there in 2-3 weeks. -Aaron On Wed, Apr 29, 2015 at 12:10 PM, Jon Robson <jdlrobson(a)gmail.com> wrote: > On Wed, Apr 29, 2015 at 8:19 AM, Robert Rohde <rarohde(a)gmail.com> wrote: > > > > On Tue, Apr 28, 2015 at 10:31 PM, Jon Robson <jrobson(a)wikimedia.org> > wrote: > > > > > <snip> > > > > Any community members interested in helping out here? I'm very sad the > > > increase in errors wasn't picked up sooner... :-/ > > > > > > > What does event_action = 'error' actually mean? > > > > If the action is stopped by the AbuseFilter is that counted as an > "error"? > > It means at some point during the editing workflow the user hit an > error that stopped them from finishing their edit. > We do capture AbuseFilter hits in this process (but with some of these > errors you can recover and complete the edit. > > We also store the error associated, although a quick scan shows this > is currently not very helpful. > > In theory 'http' error should only happen when a user cannot get an > edit token - I've updated the bug for those interested. > > > > > -Robert > > _______________________________________________ > > Wikitech-l mailing list > > Wikitech-l(a)lists.wikimedia.org > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > > > > -- > Jon Robson > * http://jonrobson.me.uk > * https://www.facebook.com/jonrobson > * @rakugojona > > _______________________________________________ > Wikitech-l mailing list > Wikitech-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l >

1 0

[Apps] Wikipedia app for Android update
by Bernd Sitzmann 30 Apr '15

30 Apr '15

Today we're pushing out a release to the production Wikipedia Android app which contains a couple of crash fixes and some other improvements. We're doing a staged rollout this time just to try that out (5% today, 20% tomorrow, and 100% on Friday). Here are more details: - Minor design tweaks to enhanced sharing feature - Fixed a bug which caused the app to sometimes make edits logged out even if you are logged in - Fixed a bug where server problems would incorrectly display as network connection problems - Improved action bar fade transition - Fixed a rare display issue with the first paragraph in articles - Improved 'Read in other languages' list - Reuse the same web view for faster article navigation - Made enter key submit captchas - Fixed several crashes Nice work, team! Cheers, Bernd

1 0

Anonymous editing impact on mobile
by Jon Robson 29 Apr '15

29 Apr '15

Anonymous editing was enabled on mobile web on 30th March 2015 to all users (previous it was available in an experimental mode of the site). Now we have almost a month's worth of data I thought it would be a good time to check the impact... it's a little disappointing to be honest... but it depends what we are optimising and consider the most important. Quick summary: * All edits up 154% * Edits from logged in users down 152% * Errors up 600% * No noticeable impact on the new active editor graph [0] (editors that hit 5 edits in the month period) * First edits by logged in users down 176% (although this could arguably be said to be compensated by anonymous edits) * New account creation up by 192% Follow ups * Aaron H, it would be great if you could report back with some findings on the quality of the edits during this same period. * Can anyone provide theories why registrations jumped so much? This might be related to the change or because of something else Details on the queries I ran: In March for a 26 day period before the change: * 170,948 total edits [1] * 169,845 non-anonymous edits [6] ** by 40,658 distinct users [7] * 26,617 users completely their first ever edit [11] * 9,528 errors [8] * 219,012 accounts created on mobile [12] For a similar 26 day period in April * 263,986 total edits [2] * 136,079 non-anonymous edits [4] ** by 26,823 distinct users [5] * 15,109 users completely their first ever edit [10] * 58,394 errors [9] * 419,976 accounts created on mobile [13] [0] http://mobile-reportcard.wmflabs.org/ [1] select count(*) from MobileWebEditing_8599025 where event_action = 'success' and timestamp > 20150301000000 and timestamp < 20150327000000 [2] select count(*) from MobileWebEditing_8599025 where event_action = 'success' and timestamp > 20150401000000 and timestamp < 20150427000000 [3] https://phabricator.wikimedia.org/T97494 [4] select count(*) from MobileWebEditing_8599025 where event_action = 'success' and timestamp > 20150401000000 and timestamp < 20150427000000 and event_username is NOT NULL [5] select count(distinct event_username) from MobileWebEditing_8599025 where event_action = 'success' and timestamp > 20150401000000 and timestamp < 20150427000000 and event_username is NOT NULL [6] select count(*) from MobileWebEditing_8599025 where event_action = 'success' and timestamp > 20150301000000 and timestamp < 20150327000000 and event_username is NOT NULL [7] select count(distinct event_username) from MobileWebEditing_8599025 where event_action = 'success' and timestamp > 20150301000000 and timestamp < 20150327000000 and event_username is NOT NULL [8] select count(*) from MobileWebEditing_8599025 where event_action = 'error' and timestamp > 20150301000000 and timestamp < 20150327000000 [9] select count(*) from MobileWebEditing_8599025 where event_action = 'error' and timestamp > 20150401000000 and timestamp < 20150427000000 [10] select count(*) from MobileWebEditing_8599025 where event_action = 'success' and timestamp > 20150401000000 and timestamp < 20150427000000 and event_userEditCount = 0 [11] select count(*) from MobileWebEditing_8599025 where event_action = 'success' and timestamp > 20150301000000 and timestamp < 20150327000000 and event_userEditCount = 0 [12] select count(*) from ServerSideAccountCreation_5487345 where event_displayMobile = 1 and timestamp > 20150301000000 and timestamp < 20150327000000 [13] select count(*) from ServerSideAccountCreation_5487345 where event_displayMobile = 1 and timestamp > 20150401000000 and timestamp < 20150427000000

2 1

Re: [WikimediaMobile] [Wikitech-l] Anonymous editing impact on mobile
by Jon Robson 29 Apr '15

29 Apr '15

In the same period during March where 219,012 accounts were created on mobile there were 228,723 accounts created on desktop [0] In the same period during April where 419,976 accounts were created on mobile there were 195,359 accounts created on desktop [1] The ServerSideAccountCreation event logging schema captures all accounts being created. I really have no idea what drove these accounts being created to surpass desktop. Could be mobile apps or mobile web - not sure. I'd encourage anyone interested who knows SQL to get access to the database and run some queries. Any community members interested in helping out here? I'm very sad the increase in errors wasn't picked up sooner... :-/ [0] select count(*) from ServerSideAccountCreation_5487345 where event_displayMobile = 0 and timestamp > 20150301000000 and timestamp < 20150327000000 [1] select count(*) from ServerSideAccountCreation_5487345 where event_displayMobile = 0 and timestamp > 20150401000000 and timestamp < 20150427000000 On Tue, Apr 28, 2015 at 8:13 PM, Risker <risker.wp(a)gmail.com> wrote: > How can edits from logged-in users be down 152%? The maximum decrease > should be 100% - and that would mean no edits from logged-in users. Same > for first edits by logged-in users. > > I seriously wonder about the number of "accounts" created on mobile - are > we really adding 0.05% of all of the current existing accounts every single > month just on mobile? Or does that include accounts that already existed > on a WMF site? > > Risker/Anne > > > > On 28 April 2015 at 20:00, Jon Robson <jrobson(a)wikimedia.org> wrote: > > > Anonymous editing was enabled on mobile web on 30th March 2015 to all > users > > (previous it was available in an experimental mode of the site). Now we > > have almost a month's worth of data I thought it would be a good time to > > check the impact... it's a little disappointing to be honest... but it > > depends what we are optimising and consider the most important. > > > > Quick summary: > > * All edits up 154% > > * Edits from logged in users down 152% > > * Errors up 600% > > * No noticeable impact on the new active editor graph [0] (editors that > hit > > 5 edits in the month period) > > * First edits by logged in users down 176% (although this could arguably > be > > said to be compensated by anonymous edits) > > * New account creation up by 192% > > > > Follow ups > > * Aaron H, it would be great if you could report back with some findings > on > > the quality of the edits during this same period. > > * Can anyone provide theories why registrations jumped so much? This > might > > be related to the change or because of something else > > > > Details on the queries I ran: > > In March for a 26 day period before the change: > > * 170,948 total edits [1] > > * 169,845 non-anonymous edits [6] > > ** by 40,658 distinct users [7] > > * 26,617 users completely their first ever edit [11] > > * 9,528 errors [8] > > * 219,012 accounts created on mobile [12] > > > > For a similar 26 day period in April > > * 263,986 total edits [2] > > * 136,079 non-anonymous edits [4] > > ** by 26,823 distinct users [5] > > * 15,109 users completely their first ever edit [10] > > * 58,394 errors [9] > > * 419,976 accounts created on mobile [13] > > > > [0] http://mobile-reportcard.wmflabs.org/ > > [1] select count(*) from MobileWebEditing_8599025 where event_action = > > 'success' and timestamp > 20150301000000 and timestamp < 20150327000000 > > [2] select count(*) from MobileWebEditing_8599025 where event_action = > > 'success' and timestamp > 20150401000000 and timestamp < 20150427000000 > > [3] https://phabricator.wikimedia.org/T97494 > > [4] select count(*) from MobileWebEditing_8599025 where event_action = > > 'success' and timestamp > 20150401000000 and timestamp < 20150427000000 > and > > event_username is NOT NULL > > [5] select count(distinct event_username) from MobileWebEditing_8599025 > > where event_action = 'success' and timestamp > 20150401000000 and > timestamp > > < 20150427000000 and event_username is NOT NULL > > [6] select count(*) from MobileWebEditing_8599025 where event_action = > > 'success' and timestamp > 20150301000000 and timestamp < 20150327000000 > and > > event_username is NOT NULL > > [7] select count(distinct event_username) from MobileWebEditing_8599025 > > where event_action = 'success' and timestamp > 20150301000000 and > timestamp > > < 20150327000000 and event_username is NOT NULL > > [8] select count(*) from MobileWebEditing_8599025 where event_action = > > 'error' and timestamp > 20150301000000 and timestamp < 20150327000000 > > [9] select count(*) from MobileWebEditing_8599025 where event_action = > > 'error' and timestamp > 20150401000000 and timestamp < 20150427000000 > > [10] select count(*) from MobileWebEditing_8599025 where event_action = > > 'success' and timestamp > 20150401000000 and timestamp < 20150427000000 > and > > event_userEditCount = 0 > > [11] select count(*) from MobileWebEditing_8599025 where event_action = > > 'success' and timestamp > 20150301000000 and timestamp < 20150327000000 > and > > event_userEditCount = 0 > > [12] select count(*) from ServerSideAccountCreation_5487345 where > > event_displayMobile = 1 and timestamp > 20150301000000 and timestamp < > > 20150327000000 > > [13] select count(*) from ServerSideAccountCreation_5487345 where > > event_displayMobile = 1 and timestamp > 20150401000000 and timestamp < > > 20150427000000 > > _______________________________________________ > > Wikitech-l mailing list > > Wikitech-l(a)lists.wikimedia.org > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > _______________________________________________ > Wikitech-l mailing list > Wikitech-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l

1 0

Inconsistent editable key in the mobileview API
by Dan Garry 29 Apr '15

29 Apr '15

I've noticed something a little strange about the "editable" key that the mobileview API returns. It seems it's either "true" or the empty string if the page is editable, or either "false" or absent from the response if the page is not editable. Whether it goes for the empty string/absent or true/false approach seems to vary from wiki to wiki. Examples (make sure you're not logged in on an admin account when you click these, because admin accounts can edit almost all pages): - Foo @ testwiki <https://test.wikipedia.org/w/api.php?action=mobileview&page=Foo&prop=editab…> - response is the empty string on an editable page - Protected page @ testwiki <https://test.wikipedia.org/w/api.php?action=mobileview&page=Protected_page&…> - response is absent on a protected page - Manchester @ enwiki <https://en.wikipedia.org/w/api.php?action=mobileview&page=Manchester&prop=e…> - response is true on an editable page - Barack Obama @ enwiki <https://en.wikipedia.org/w/api.php?action=mobileview&page=Barack%20Obama&pr…> - response is false on a protected page Does anyone know why this is? It'd be nice if this could be changed, because it's a pain to deal with things like this in a strongly-typed language like Java. Thanks, Dan -- Dan Garry Product Manager, Search and Discovery Wikimedia Foundation

3 4

Gather Sprint Greatest Hits kicked off
by Jon Robson 29 Apr '15

29 Apr '15

The team responsible for the Gather extension [0] kicked off their new sprint yesterday. sprint `Greatest Hits` [1] after finishing sprint `Forward` completing 33.5 story points (3.5 more than we planned). As well as the usual polish, this sprint we will be doing lots of thinking around the topics of flagging [2] and subscribing [3] for the backend for the Gather feature. These will help steer our architecture in the right direction. Please join the conversation. In addition to this we are planning to make some changes to target some of our users and encourage them to opt into our beta site to grow our audience there for beta testing so we can reach more users than we have historically been able to [2]. [0] https://www.mediawiki.org/wiki/Extension:Gather [1] https://phabricator.wikimedia.org/tag/gather_sprint_greatest_hits/ [2] https://phabricator.wikimedia.org/T96282 [3] https://phabricator.wikimedia.org/T94243 [4] https://phabricator.wikimedia.org/T96286

1 0

Re: [WikimediaMobile] [Wikimedia-l] Google rankings and mobile phone support`
by Pine W 28 Apr '15

28 Apr '15

Hi Gerard, Yes, I saw this news as well. Check out these results: https://www.google.com/webmasters/tools/mobile-friendly/?url=www.wikipedia.… https://www.google.com/webmasters/tools/mobile-friendly/?url=en.wikipedia.o… https://www.google.com/webmasters/tools/mobile-friendly/?url=commons.wikime… https://www.google.com/webmasters/tools/mobile-friendly/?url=www.wikimediaf… https://www.google.com/webmasters/tools/mobile-friendly/?url=www.wikimedia.… https://www.google.com/webmasters/tools/mobile-friendly/?url=blog.wikimedia… It looks like most but not all Wikimedia sites pass Google's test. Personally I hope we invest heavily in Mobile Web in the next annual plan. I would like to see growth in mobile readership and growth in mobile contributions, and year-over-year growth in combined desktop and mobile readership and contributions. Thanks, Pine *This is an Encyclopedia* <https://www.wikipedia.org/> *One gateway to the wide garden of knowledge, where lies The deep rock of our past, in which we must delve The well of our future,The clear water we must leave untainted for those who come after us,The fertile earth, in which truth may grow in bright places, tended by many hands,And the broad fall of sunshine, warming our first steps toward knowing how much we do not know.* *—Catherine Munro* On Sun, Apr 26, 2015 at 11:24 PM, Gerard Meijssen <gerard.meijssen(a)gmail.com > wrote: > Hoi, > > It is all over the news. Google will push mobile phone support by changing > its ranking algorithm. A website that does not support mobiles well will > suffer the consequences. Several sources like /. indicate that Wikipedia > has a problem. > > I am anxious to learn what we are going to do. > > From my perspective this is not a time of endless deliberations; we have > done that, we have been there. Mobile is where we grow. It seems to me a no > brainer that we will move lock stock and barrel to a more mobile friendly > environment. > > Thanks. > GerardM > > > http://ultimategerardm.blogspot.nl/2015/04/google-thank-you-for-pushing-mob… > _______________________________________________ > Wikimedia-l mailing list, guidelines at: > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines > Wikimedia-l(a)lists.wikimedia.org > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, > <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>

3 2

Fwd: [Wikimedia-l] Google rankings and mobile phone support`
by Adam Baso 27 Apr '15

27 Apr '15

Cross posting to mobile-l. ---------- Forwarded message ---------- From: Gerard Meijssen <gerard.meijssen(a)gmail.com> Date: Sun, Apr 26, 2015 at 11:54 PM Subject: Re: [Wikimedia-l] Google rankings and mobile phone support` To: Wikimedia Mailing List <wikimedia-l(a)lists.wikimedia.org> Cc: WikiData-l <wikidata-l(a)lists.wikimedia.org> Hoi Pine, Thanks for the link to the test tool. <grin> I find that the one project dearest to my heart is doing poorly </grin>. It seems that our projects themselves are fairing much better than what the news led me to believe.. The point of it all is that mobile phones need to be well supported. It is good that we are working strongly on improving our mobile presence and the software and the group of readers they represent are becoming main-stream as time progresses. Thanks, GerardM On 27 April 2015 at 08:41, Pine W <wiki.pine(a)gmail.com> wrote: > Hi Gerard, > > Yes, I saw this news as well. > > Check out these results: > > > https://www.google.com/webmasters/tools/mobile-friendly/?url=www.wikipedia.… > > > https://www.google.com/webmasters/tools/mobile-friendly/?url=en.wikipedia.o… > > > https://www.google.com/webmasters/tools/mobile-friendly/?url=commons.wikime… > > > https://www.google.com/webmasters/tools/mobile-friendly/?url=www.wikimediaf… > > > https://www.google.com/webmasters/tools/mobile-friendly/?url=www.wikimedia.… > > > https://www.google.com/webmasters/tools/mobile-friendly/?url=blog.wikimedia… > > It looks like most but not all Wikimedia sites pass Google's test. > > Personally I hope we invest heavily in Mobile Web in the next annual plan. > I would like to see growth in mobile readership and growth in mobile > contributions, and year-over-year growth in combined desktop and mobile > readership and contributions. > > Thanks, > > Pine > > *This is an Encyclopedia* <https://www.wikipedia.org/> > > > > > > > *One gateway to the wide garden of knowledge, where lies The deep rock of > our past, in which we must delve The well of our future,The clear water we > must leave untainted for those who come after us,The fertile earth, in > which truth may grow in bright places, tended by many hands,And the broad > fall of sunshine, warming our first steps toward knowing how much we do not > know.* > > *—Catherine Munro* > > On Sun, Apr 26, 2015 at 11:24 PM, Gerard Meijssen < > gerard.meijssen(a)gmail.com > > wrote: > > > Hoi, > > > > It is all over the news. Google will push mobile phone support by > changing > > its ranking algorithm. A website that does not support mobiles well will > > suffer the consequences. Several sources like /. indicate that Wikipedia > > has a problem. > > > > I am anxious to learn what we are going to do. > > > > From my perspective this is not a time of endless deliberations; we have > > done that, we have been there. Mobile is where we grow. It seems to me a > no > > brainer that we will move lock stock and barrel to a more mobile friendly > > environment. > > > > Thanks. > > GerardM > > > > > > > http://ultimategerardm.blogspot.nl/2015/04/google-thank-you-for-pushing-mob… > > _______________________________________________ > > Wikimedia-l mailing list, guidelines at: > > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines > > Wikimedia-l(a)lists.wikimedia.org > > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, > > <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe> > _______________________________________________ > Wikimedia-l mailing list, guidelines at: > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines > Wikimedia-l(a)lists.wikimedia.org > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, > <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe> _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l(a)lists.wikimedia.org <https://meta.wikimedia.org/wiki/Mailing_lists/GuidelinesWikimedia-l@lists.w…> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>

1 0

Fwd: Mediawiki-api-announce Digest, Vol 27, Issue 2
by Adam Baso 27 Apr '15

27 Apr '15

FYI. If your software interacts with the API, good list to join. ---------- Forwarded message ---------- From: <mediawiki-api-announce-request(a)lists.wikimedia.org> Date: Sunday, April 26, 2015 Subject: Mediawiki-api-announce Digest, Vol Today's Topics: Date: Sat, 25 Apr 2015 08:30:32 -0400 From: "Brad Jorsch (Anomie)" <bjorsch(a)wikimedia.org <javascript:;>> To: mediawiki-api-announce(a)lists.wikimedia.org <javascript:;> Subject: [Mediawiki-api-announce] Change in ordering of revisions from prop=revisions prop=revisions has long ordered revisions by rev_id rather than timestamp when returning results for a single page. In most cases this doesn't make a difference, but for old pages imported from earlier versions of Wikipedia, for revisions imported from Special:Import, and so on these orderings don't always match. prop=revisions has now been updated[1] to order by timestamp rather than id. While this is technically a breaking change, it seems unlikely that any clients will actually be broken by this. This should be deployed to WMF wikis with 1.26wmf4, see https://www.mediawiki.org/wiki/MediaWiki_1.26/Roadmap for the schedule. [1]: https://gerrit.wikimedia.org/r/#/c/188843/ -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation

1 0

Android Wikipedia beta app release
by Bernd Sitzmann 24 Apr '15

24 Apr '15

Dear Android app friends, Around an hour ago I pushed out a new release for the beta app, so it should be available fairly soon. Unless there are major issues/blockers discovered, we're going to push this code base to production next week. Changes for 2.0-beta-2015-04-23 include: * Detect network connectivity, and display server status code & message in case of error instead of assuming that network is down * Avoid IP edits when user is logged in * Don't display "read more" suggestions outside main namespace * Slightly decrease minimum text size on Share a Fact cards * Prevent action bar from reverting to black on new page load if lead image is available Crash fixes: * Fix possible crash on screen rotation * Disable pulling of ToC before page has finished loading Enjoy, Bernd

1 0

Moderation tools [was Re: Commons Reloaded]
by Luis Villa 22 Apr '15

22 Apr '15

On Wed, Apr 15, 2015 at 11:16 AM, Jon Robson <jdlrobson(a)gmail.com> wrote: > > I'm just troubled by some of the language used here, and elsewhere, which > > describes a "fear" of more users. I can't help but wonder how many > companies > > or services would readily welcome a "massive influx of users." How will > > Wikipedia or Commons succeed if we're afraid growth? > > +1. How we change this culture is the holy grail of Wikimedia's > future. Unless we change this, our project will die imo. I was really > saddened to see mobile uploads disappear from web - we had a lot of > spam yes but we also had people posting never before available photos > of diseases [1]. Our communities reaction seems to be to push back on > influxes of new edits which makes me feel we should be spending more > time on moderation tools - but so far I don't see any hint that this > will become a focus. This is a bigger problem than web and apps but so > far we see this more than most... I think this is something we'd have > to convince Lila is a good use of our time... Lila is convinced it is a good use of time; that's why tools for community needs was in the Call To Action. And that's why we announced the creation of a Community Tech team yesterday (see wikimedia-l). Details and prioritization are still to be fleshed out (they can't tackle everything at once!) but moderation tools are definitely one of the things the team could tackle. Luis -- Luis Villa Sr. Director of Community Engagement Wikimedia Foundation *Working towards a world in which every single human being can freely share in the sum of all knowledge.*

4 3

Collections is more popular than watchlist... so far ; -)
by Jon Robson 22 Apr '15

22 Apr '15

In beta on enwiki, there were 400 clicks on watchlist compared to 587 on collections since we launched it. It will be interesting how it holds out, as I suspect it is "new feature curiosity" but it adds more value to the idea that people use the watchlist for things other than editing. It's even more popular than nearby at current time. That said It still fails to compete with our most popular 'features' home, random and settings. Result of SQL Query [1]: Home Random Nearby Watchlist Uploads Settings Profile Logout Login Collections 1308 851 500 400 0 1188 258 99 373 587 [1] SELECT sum(if(event_name = 'home', 1, 0)) as Home, sum(if(event_name = 'random', 1, 0)) as Random, sum(if(event_name = 'nearby', 1, 0)) as Nearby, sum(if(event_name = 'watchlist', 1, 0)) as Watchlist, sum(if(event_name = 'uploads', 1, 0)) as Uploads, sum(if(event_name = 'settings', 1, 0)) as Settings, sum(if(event_name = 'profile', 1, 0)) as Profile, sum(if(event_name = 'logout', 1, 0)) as Logout, sum(if(event_name = 'login', 1, 0)) as Login, sum(if(event_name = 'collections', 1, 0)) as Collections FROM MobileWebMainMenuClickTracking_11568715 WHERE event_mobileMode = 'beta' and wiki = 'enwiki'

6 8

[Web] I ran this one Python script and look at all the Wikidata edits it made
by Sam Smith 22 Apr '15

22 Apr '15

Hey folks, One of the tasks that the Readership* team committed to this sprint was running the WikiGrok bot [0] to aggregate and push all previously recorded claims to Wikidata [1]. We agreed that for this first run, the bot should use a conservative threshold to judge what qualifies as a pushable claim: there must be at least 10 responses to the WikiGrok question and 80% of those responses must be for the claim. 120 claims qualified as pushable and, eventually, 78 were pushed to Wikidata [2]. –Sam * We're going to have to come up with a new name again, aren't we? [0] https://github.com/phuedx/wikigrok-aggregation-test [1] https://phabricator.wikimedia.org/T96096 [2] https://www.wikidata.org/w/index.php?title=Special:Contributions/WikiGrok&o…

1 0

Wikimedia Foundation quarterly reviews
by Tilman Bayer 22 Apr '15

22 Apr '15

Hi all, the quarterly reviews for the past quarter (January-March 2015) took place last week. Minutes and slides are now available for the following meetings: Community Engagement, Advancement (Fundraising and Fundraising Tech): https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarter… Mobile Web, Mobile Apps, Wikipedia Zero: https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarter… Parsoid, Services, MediaWiki Core, Tech Ops, Release Engineering, Multimedia, Labs, Engineering Community: https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarter… Editing (covering VisualEditor), Collaboration (covering Flow), Language Engineering: https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarter… As mentioned in February [1], the quarterly review process has been extended to basically all groups in the Foundation since Lila took the helm last year, and it was further refined this quarter, reducing the number of meetings to six overall, each combining several areas. Minutes and slides from the remaining two meetings should come out soon, too. (And naturally, all the engineering team names above refer to the structure before the reorganization that has just been announced.) [1] https://lists.wikimedia.org/pipermail/wikimedia-l/2015-February/076835.html On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller <erik(a)wikimedia.org> wrote: > > Hi folks, > > to increase accountability and create more opportunities for course > corrections and resourcing adjustments as necessary, Sue's asked me > and Howie Fung to set up a quarterly project evaluation process, > starting with our highest priority initiatives. These are, according > to Sue's narrowing focus recommendations which were approved by the > Board [1]: > > - Visual Editor > - Mobile (mobile contributions + Wikipedia Zero) > - Editor Engagement (also known as the E2 and E3 teams) > - Funds Dissemination Committe and expanded grant-making capacity > > I'm proposing the following initial schedule: > > January: > - Editor Engagement Experiments > > February: > - Visual Editor > - Mobile (Contribs + Zero) > > March: > - Editor Engagement Features (Echo, Flow projects) > - Funds Dissemination Committee > > We’ll try doing this on the same day or adjacent to the monthly > metrics meetings [2], since the team(s) will give a presentation on > their recent progress, which will help set some context that would > otherwise need to be covered in the quarterly review itself. This will > also create open opportunities for feedback and questions. > > My goal is to do this in a manner where even though the quarterly > review meetings themselves are internal, the outcomes are captured as > meeting minutes and shared publicly, which is why I'm starting this > discussion on a public list as well. I've created a wiki page here > which we can use to discuss the concept further: > > https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings/Quarterly_r… > > The internal review will, at minimum, include: > > Sue Gardner > myself > Howie Fung > Team members and relevant director(s) > Designated minute-taker > > So for example, for Visual Editor, the review team would be the Visual > Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker. > > I imagine the structure of the review roughly as follows, with a > duration of about 2 1/2 hours divided into 25-30 minute blocks: > > - Brief team intro and recap of team's activities through the quarter, > compared with goals > - Drill into goals and targets: Did we achieve what we said we would? > - Review of challenges, blockers and successes > - Discussion of proposed changes (e.g. resourcing, targets) and other > action items > - Buffer time, debriefing > > Once again, the primary purpose of these reviews is to create improved > structures for internal accountability, escalation points in cases > where serious changes are necessary, and transparency to the world. > > In addition to these priority initiatives, my recommendation would be > to conduct quarterly reviews for any activity that requires more than > a set amount of resources (people/dollars). These additional reviews > may however be conducted in a more lightweight manner and internally > to the departments. We’re slowly getting into that habit in > engineering. > > As we pilot this process, the format of the high priority reviews can > help inform and support reviews across the organization. > > Feedback and questions are appreciated. > > All best, > Erik > > [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus > [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings > -- > Erik Möller > VP of Engineering and Product Development, Wikimedia Foundation > > Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate > > _______________________________________________ > Wikimedia-l mailing list > Wikimedia-l(a)lists.wikimedia.org > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l -- Tilman Bayer Senior Analyst Wikimedia Foundation IRC (Freenode): HaeB

1 0

Mobile Newsletter?
by Moushira Elamrawy 21 Apr '15

21 Apr '15

Hello Mobile fans :) Florian and and myself earlier created a draft for a Mobile Newsletter: https://www.mediawiki.org/wiki/Mobile/Newsletter -- it is currently a bit outdated since it has been around for a while. Given the comments on phab ticket. https://phabricator.wikimedia.org/T93529, it is likely that this needs to be streamlined with other newsletters, however, meanwhile the coordination, please check and let me know: 1. What would be the best approach to create it --agree on sections (new features, testing, etc) where volunteers, PMs and CL add details to? 2. This format is too detailed? Too brief? What else do we need to see on a newsletter for mobile? Obviously, it has to be made mobile friendly, as well. :) Comments, suggestions, thoughts? Many Thanks! Moushira

3 3

Commons Reloaded
by Maarten Dammers 18 Apr '15

18 Apr '15

Hi everyone, The old Commons mobile app got forked, see https://itunes.apple.com/de/app/commons-reloaded/id962894692?mt=8 and https://github.com/lyrk/Commons :-) Maarten

17 33

Removing MobileFrontend from Gather dependencies
by Jon Robson 15 Apr '15

15 Apr '15

I did a quick spike [1] to work out how Gather could stop depending on MobileFrontend. Essentially problems come into 2 categories: 1) Finding a place for Gather in the desktop skin and addressing styling issues in desktop skins (I am working on these and don't see any major blockers here). I think to fix this we simply need to provide Gather as a desktop beta feature. This is tracked here: https://phabricator.wikimedia.org/T95227 and I see no issues with doing this. 2) frontend code standardisation The main problem with the hard dependency is that MobileFrontend uses a library that was built around the same time as OOJSUI. Migrating MobileFrontend to use OOJSUI is a big task and although has happened somewhat (the codebase now uses OOJS for class inheritance) it is by no means complete. Gather current depends on a variety of MobileFrontend modules which mainly include: API, overlay, user and user setting code, EventLogging schema code, notifications code. We also have a method mw.mobileFrontend.require and mw.mobileFrontend.define for defining modules. OOJS ui does this differently writing class names to the OO global variable object. ==The long term fix=== ... is obviously to migrate all the code to OOJS UI which I believe would require the following steps: * https://phabricator.wikimedia.org/T88559 which as an end result will rewrite overlay code in oojs ui * Rewriting mw.util.notify as an oo js ui component and folding the mobile toast notification into it. - https://phabricator.wikimedia.org/T66565 * Core should have a way to store user settings in localStorage rather than using $.cookie (similar to M.require( 'settings' ) ) - something akin to https://phabricator.wikimedia.org/T67008 * EventLogging Schema.js should be ported to oojs ui and moved into core. * We only use user for the getEditCount function - it would be trivial to rewrite using mw.user == the short term fix== We could split out the frontend library MobileFrontend uses to allow us to share it between Gather and MobileFrontend. The way I see this working is to merge all the shared generic JS code into its own project just like oojs ui and slowly rewrite it there till it is pure oo js ui. This would take everything in the javascripts/common/ folder except application.js and bundle it into one file. We could include this as a submodule in both projects, both extensions conditionally adding a RL module for it when it does not exist. What do people think about taking this approach on the short term? [1] https://phabricator.wikimedia.org/T94100

6 7

[Web] Existing MF data series in Graphite/on gdash
by Sam Smith 15 Apr '15

15 Apr '15

Hey y'all, As part of Mobile Web Sprint 45: Snakes on a Plane, the Readership team picked up a spike to investigate what data, if any, we were logging around site speed [0], given the existence of the mobile graphs over at WMF stats [1]. After a little poking around I found that all of the NavigationTiming data that's collected by the eponymous extension is already separated out into desktop and mobile series in Graphite [2]. Any or all of these series can be graphed in gdash by defining our own graphs [3]. With this in mind I've closed the tasks to design and implement our own event logging for site speed as invalid – don't you just love it when work's already done for you? Furthermore, if we find, some time in the future, that we want do refine the data that's being collected, then we have a clearly defined workflow: design the schema with the help of analytics, instrument the schema, and then define a graph. You'll note that only the first step requires collaboration (i.e. synchronisation) with another team. Woo! –Sam [0] https://phabricator.wikimedia.org/T95296 [1] https://gdash.wikimedia.org/dashboards/frontend/ [2] https://graphite.wikimedia.org – have a good look around frontend - navtiming [3] https://github.com/wikimedia/operations-puppet/tree/production/files/gdash/…

3 3

Wikipedia for iOS 4.1.0 Launched
by Adam Baso 15 Apr '15

15 Apr '15

:) https://blog.wikimedia.org/2015/04/15/new-release-wikipedia-app-ios/ Great work everyone. -Adam

1 0

Fixed Android alpha build
by Bernd Sitzmann 15 Apr '15

15 Apr '15

FYI. I just fixed the alpha build for the Android app. ( http://android-builds.wmflabs.org/) It had issues with the java-mwapi dependency. It was most likely cause by one of the recent labs outages (the team Maven repo, which hosts only this library, is also on tool labs). More details on https://phabricator.wikimedia.org/T96102. Bernd

1 0

No one cares about browser tests [Re: [QA] MobileFrontend QA job]
by Jon Robson 14 Apr '15

14 Apr '15

It really saddens me how very few engineers seem to care about browser tests. Our browser tests are failing all over the place. I just saw this bug [1] which has been sitting around for ages and denying us green tests in Echo one of our most important features. How can we change this anti-pattern? Dan Duval, would it make sense to do a survey as you did with Vagrant to understand how our developers think of these? Such as who owns them... who is responsible for a test failing... who writes them... who doesn't understand them.. why they don't understand them etc...? [1] https://phabricator.wikimedia.org/T72298 On Thu, Mar 26, 2015 at 5:54 PM, Dan Duvall <dduvall(a)wikimedia.org> wrote: > On Thu, Mar 26, 2015 at 3:38 PM, Jon Robson <jdlrobson(a)gmail.com> wrote: > > The lack of replies from any mobile team members seems to suggest I'm the > > only one watching this. In that case I'd rather we split up the big > > MobileFrontend job into various jobs based on certain features. How can > we > > get more people caring about browser tests? Naming and shaming? > > We have a couple projects in the works that will hopefully help.[1][2] > They don't go so far as to name and shame (we'll leave that up to you > :), but they should promote more ownership over browser tests, better > communication of failure, and analysis of failure over time and by > test function (feature vs smoke vs regression). > > If many of these browser tests are serving as regression/smoke tests, > it might be worthwhile to not only separate them out, but to remove > some of the layers of abstraction to make tests more maintainable. I > often try to think about tests in terms of a value-to-debt ratio (i.e. > "How likely is it that I'll have to fix or refactor this test down the > road and is it worth it?") and, while I find quite a bit of value in > Cucumber for the sake of acceptance(-esque) testing (it keeps me > mindful of the UX),[3] it introduces quite a bit of debt in its layers > of abstraction and indirection (it's always a red flag when you have > to grep to find your test implementation). Even its creators believe > the value of Cucumber lies in its collaboration/planning capacities, > not in its function as a test runner.[4] > > It's entirely possible, as of the 1.0.0 release, to use MW-Selenium > without Cucumber, so perhaps we could experiment with simple RSpec > examples for these types of tests. > > Tooling aside, there are broader discussions that need to take place > among those that are practicing or have practiced TDD/BDD in the > organization and how we might (or might not) promote theses practices > among others. I'll be trying to form such a group next quarter (will > it be a 'guild'?, a 'league'?, no need for tough decisions just > yet[5]), so let's maintain a dialogue on that front if you're > interested and willing. > > [1] https://phabricator.wikimedia.org/T88706 > [2] https://phabricator.wikimedia.org/T89375 > [3] > https://gerrit.wikimedia.org/r/#/c/196492/10/features/role_settings.feature > [4] > https://cukes.info/blog/2014/03/03/the-worlds-most-misunderstood-collaborat… > [5] https://www.youtube.com/watch?v=6KSiyaqnZYs > > > Practically, the current big job [1] we have has far too many false > > positives and it is just noise to me. I was paying attention to the smoke > > tests [2] but I was told that was an upstream bug and haven't been > watching > > it since. Any idea why that has been failing recently? Nothing has broken > > here... > > > > [1] > > > https://integration.wikimedia.org/ci/view/Mobile/job/browsertests-MobileFro… > > [2] > > > https://integration.wikimedia.org/ci/view/Mobile/job/browsertests-MobileFro… > > > > Have you tried to reproduce these failures by executing the tests > locally, against either Beta or your local MW? I'll be in the office > tomorrow if you want advice on how to best go about it. > > Dan > > -- > Dan Duvall > Automation Engineer > Wikimedia Foundation > -- Jon Robson * http://jonrobson.me.uk * https://www.facebook.com/jonrobson * @rakugojon

6 7

[Web] MediaWiki: MobileFrontend dashboard
by Sam Smith 14 Apr '15

14 Apr '15

Hey y'all, Anyone know what powers, or more correctly what *should* power, the MediaWiki: MobileFrontend dashboard [0]? I'm hoping that it's data from the NavigationTiming extension but I've been known to be wrong. –Sam [0] https://gdash.wikimedia.org/dashboards/mobext/

1 0

Android Wikipedia beta app release
by Bernd Sitzmann 11 Apr '15

11 Apr '15

Dear Android app friends, Around an hour ago I pushed out a new release for the beta app, so it should be available fairly soon. Changes for beta / 2015-04-10 [1] include: * Show local page titles in language list entries of 'Read in other languages' * ShareAFact: correctly align WP wordmark for RTL * Fix issue with moving the first paragraph in some articles * Fix missing period at the end of first sentence in some articles * Hide search bar on saved pages and history sections if none exist * Fix issue where ToC onboarding screen was not shown but the ToC was when visiting subsequent pages * Make enter key submit request when the user is filling in a captcha Enjoy, Bernd [1] This is versionCode 100! Yeah!

1 0

[Apps] Using Swift for new feature development on iOS
by Dan Garry 10 Apr '15

10 Apr '15

*tl;dr: The programming language used to develop new features by our iOS app engineering team is changing from Objective C to Swift at some point in the near future.* When making a native app, the language you have to implement the app in is chosen by the third party responsible for the platform. For iOS apps, Apple chose Objective C to be the language the app is written in. Objective C is a... very strange language. It has a lot of quirks that slow down development. To solve the above problem, you can now write apps in a new language called Swift. Notably, Swift has features that make it less error prone and more concise than Objective C, which should increase our velocity of feature development. Swift is also much more readable and in-line with other languages, which lowers the barrier of entry (which is currently very high with Objective C). Importantly, Objective C and Swift can live alongside each other. So, when we "switch to Swift" we do not need to rewrite all of our existing code from Objective C to Swift. Instead, we can just start developing new features using Swift, and slowly rewrite the old code from Objective C into Swift as time allows. On the downsides, Swift is only supported on iOS 7 and above. iOS 6 only represents around 5% of our user base, and we can pin iOS 6 users to the last version of the app we released before we used Swift. We need to decide what the last set of features we're want in that build are before we switch. Here are our next steps: - Evaluate more concretely whether Swift actually fits our needs or not. [Engineering] - Decide last set of features for our iOS 6 build. [Product/Design] Thanks, Dan -- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation

5 9

Fwd: [Apps] Stripping content inside brackets from the first sentence of articles
by Derk-Jan Hartman 10 Apr '15

10 Apr '15

---------- Forwarded message ---------- From: Derk-Jan Hartman <d.j.hartman+wmf_ml(a)gmail.com> Date: Thu, Apr 9, 2015 at 4:50 PM Subject: Re: [WikimediaMobile] [Apps] Stripping content inside brackets from the first sentence of articles On 9 apr. 2015, at 08:44, Dan Garry <dgarry(a)wikimedia.org> wrote: Hey Derk-Jan, Thanks for chiming in. It's great to have your input. On 8 April 2015 at 23:22, Derk-Jan Hartman <d.j.hartman+wmf_ml(a)gmail.com> wrote: > > This is me waving my red flag and telling you that you are walking > into/picking a huge fight with ‘the community’. You can’t win anything > here, there will only be losers. > As a long time community member myself, I am aware of how contentious this change is. But I disagree that there will only be losers, as there are plenty of readers who will benefit from the change. My experience with WMF launches shows me that there are a few golden rules: 1: Don’t do contentious changes without working on the root causes of why some things are contentious 2: Measure the shit out of it. 3: Be prepared that it will still be contentious and rollback. 4: Analyze the data, find more solutions > If you want to convince users that something needs to be done here, you > should consider handing tools to the community to detect that something is > wrong. Like https://meta.wikimedia.org/wiki/File_metadata_cleanup_drive I'd love to solve this more systematically. What are your suggestions for how we could do that? We've not had much luck thinking of any so far. Isolate: 1: Measure user response to the bracketed text 2: Graph user response to the bracketed text 3: Add graph to every single follow up action that you do 4: First add all the code to parse what is in there. 5: Log what is in there (or do it based on a db dump) 6: Classify what is in there (yes, that means manual labour, make it a wikigrok-like game ? ) Note, the long tail is probably more interesting here than the 80% that you already know about. 7: Ask for semantic classes and help rolling them out, so it is easier to strip this stuff. 8: Start by stripping things that are duplicate (if in infobox then strip, else not) 9: Selectively strip something like IPA, because you have measured that people are not interested in it 10: Intelligently output what remains in there (if everything hidden, skip the () altogether, take care of trailing , etc). Hope that helps you forward. DJ

1 0

Re: [WikimediaMobile] Great Expectations
by Adam Baso 10 Apr '15

10 Apr '15

Moving discussion over to mobile-l. Clever subject. On Wed, Apr 8, 2015 at 6:54 PM, Brian Gerstle wrote: > I didn't mean to suggest you can't mix and match. The author of that > article endorses Specta/Expecta and OCMockito, but AFAIK Expecta matchers > still aren't natively supported in OCMockito > <https://github.com/jonreid/OCMockito/issues/56>. Whereas OCHamcrest can > be used inside OCMockito expressions > <https://github.com/jonreid/OCMockito#argument-matchers>. > > On Wed, Apr 8, 2015 at 9:45 PM, Corey Floyd <cfloyd(a)wikimedia.org> wrote: > >> Looks like Expecta / Specta are able to work with OCMockito pretty well >> actually, so that shouldn’t be a concern: >> >> http://www.annema.me/why-i-prefer-testing-with-specta-expecta-and-ocmockito >> >> There are even some nice Xcode templates with OCMockito/Specta/Expecta: >> https://github.com/mtynior/SpectaXcodeTemplates >> >> Even though we haven’t written any Swift yet, we should look into those >> new libraries as well for completeness. >> >> On Wed, Apr 8, 2015 at 9:07 PM, Brian Gerstle wrote: >> >>> The other two new kids on the block are Quick >>> <https://github.com/quick/quick> (BDD specs, similar to Specta) and >>> Nimble <https://github.com/Quick/Nimble> (expectations). The main >>> advantage of these two are Swift & ObjC compatibility (future-proof). >>> >>> Here's how I see w.r.t. matching frameworks, since IMO BDD stuff is >>> orthogonal: >>> >>> - OCHamcrest >>> - pros >>> - it integrates *really* nicely w/ OCMockito (same author) >>> - we could try to write adapters for Nimble/Expecta >>> matchers, but IMO it's tedious >>> - also assumes we're using OCMockito too (mocking isn't >>> really possible in Swift yet due to the lack of a reflection API) >>> - assertion failures are nicer than XCTest >>> - cons >>> - API is macro-heavy and clunky, but gets teh job done >>> - Expecta >>> - pros: >>> - really nice API, even has crazy "objectification" so you >>> don't need to box primitives (i.e. expect(YES).to(beTrue()) just works) >>> - has async matchers >>> - cons: >>> - not compatible w/ any mocking frameworks AFAIK >>> - Nimble >>> - pros: >>> - really nice API, similar to Expecta >>> - also has async matchers >>> - built with Swift in mind, but maps really well to ObjC >>> - cons >>> - minor, but doesn't have auto-boxing of primitives like >>> Expecta does, but that's not necessary in swift anyway >>> - uses bleeding-edge swift language features, so you need >>> Xcode 6.3 beta to run it >>> >>> For now, Id vote for sticking w/ OCHamcrest given that we're using >>> OCMockito. There's also OCMock, which I have experience with, which also >>> accepts OCHamcrest matchers. >>> >>> That being said, we can always use Nimble in Swift tests :-) >>> >>> On Wed, Apr 8, 2015 at 8:59 PM, Corey Floyd wrote: >>> >>>> Hey guys keep forgetting to write this… We added OCHamcrest before we >>>> really started formally evaluating 3rd party libs. So wanted to open the >>>> discussion now, especially since we have been writing tests in earnest. >>>> Also I hadn’t used OCHamcrest before, so wanted to try it out for a bit >>>> before discussing. >>>> >>>> After looking around it looks like Expecta ( >>>> https://github.com/specta/expecta) is the other big matcher framework. >>>> These 2 articles compare Expecta and OCHamcrest: >>>> >>>> http://appleprogramming.com/blog/2014/01/18/tdd-with-specta-and-expecta/ >>>> http://pivotallabs.com/expectations-in-ios-testing/ >>>> >>>> Personally, I find the Expecta matchers much more readable to >>>> OCHamcrest. >>>> >>>> This is confirmed when I read our OCHamcrest code. I notice that my >>>> eyes have to bounce around a bit to actually understand what is happening. >>>> The expectation is nested at the end and sometimes you jam in a description >>>> in the middle which makes me stop and look at it for a bit. This is an >>>> example in our code: >>>> >>>> assertThat((a)([self.controller.fetchedIndices >>>> containsIndexesInRange:attemptedBatch]), >>>> describedAs(@"batch range to be optimistically marked as >>>> 'fetched'", >>>> isTrue(), nil)); >>>> >>>> I don’t know if we need to say we can only write tests using one >>>> framework or another, but we should probably discus it as a group and then >>>> formalize it into a best practice. >>>> >>>> >>>> Related to this conversation is Specta ( >>>> https://github.com/specta/specta) which can be used with either >>>> Expecta or OCHamcrest but adds some BDD syntax. >>>> >>>

1 0

[Apps][iOS]
by Corey Floyd 09 Apr '15

09 Apr '15

We are currently evaluating some 3rd party image caching libraries for use in the iOS app. At the moment, we have our own caching layer which is a bit entangled in our data layer. We are making some changes to better encapsulate image caching now, but as we do, we are also evaluating these libraries which are general purpose and used throughout the iOS community. This website gives a great rundown of the available libraries and why you would choose to incorporate one: https://bpoplauschi.wordpress.com/2014/03/21/ios-image-caching-sdwebimage-v… As the title suggests we are currently looking most closely at SDWebImage and FastImageCache. If you have any insights or feedback please feel free to post here. Thanks! -- Corey Floyd Software Engineer Mobile Apps / iOS Wikimedia Foundation

1 0

MobileFrontend and module deprecation
by Florian Schmidt 08 Apr '15

08 Apr '15

Recently i noticed, that Jon wants to deprecate a module (he moved it to another location and changed the module name)[1], so I thought about a better way of deprecating a module (like core functions with a visible deprecation warning in the browser console, e.g.). So I uploaded a change for review[2] to extend module.js to support the definition of a deprecated module (it will log a warning every time someone access the module with M.require). Jon already posted, that he don't know, if this is the right approach and suggested to extend core's mw.log.deprecate. I'm not sure, if it's a better approach to extend a core module in this way, so I hope for some feedback on this mailing list: What do you think? :) [1] https://gerrit.wikimedia.org/r/#/c/202053/3/javascripts/ContentOverlay.js [2] https://gerrit.wikimedia.org/r/#/c/202069/ Best, Florian

3 4

Templates in core, let's use them
by Joaquin Oltra Hernandez 06 Apr '15

06 Apr '15

Given templates are in core now, usable from both JS and PHP, do you guys think we should halt HTML generation with PHP and make all future HTML generation with templates, and slowly migrate existing HTML generation to templates (in mobile web projects)? Thanks for all the work on getting this done, it is awesome. Docs: https://www.mediawiki.org/wiki/Manual:HTML_templates#mw.template_.28client-…

3 2

Android Wikipedia beta app release
by Bernd Sitzmann 06 Apr '15

06 Apr '15

Just pushed out a new release for the beta app, which should be available soon. beta / 2015-04-03 (versionCode 99... Luftballons) ================== Page load performance: * Reuse the same WebView for article navigation. -> No animations between page transitions anymore. * Reduce size of face detection image Design: * ShareAFact: use static image for English WP wordmark * Display local article name in 'Read in other languages' list Bugs: * Fix possible crash when failing to clear shared image folder. * Fix possible crash when highlighting text to share. Please report any new bugs you encounter. Enjoy, Bernd

2 1

Wikipedia Android App running with ARC Welder on OSX
by Tomasz Finc 04 Apr '15

04 Apr '15

I just took Googles new Chrome/Android (LLVM & Arc) bridge "ARC Welder" for a spin with the Wikipedia Android App and I've very impressed with how smoothly everything works. Near By, Saved pages, theme switching, etc all work flawlessly. Minus not being able to figure out the hardware back button it looks lovely. This really showcases how future proof we are by being native. Excited to see what else we find out at I/O. Screenshots: https://imgur.com/a/LxQ99 --tomasz [1] - https://developer.chrome.com/apps/getstarted_arc

3 3

DHH Testing Key Note at Railsconf 2014
by Corey Floyd 03 Apr '15

03 Apr '15

This is from a while back, but I finally got around to watching it. I think it is a really good questioning of our assumptions around testing (and of course it is a controversial talk - it is DHH) To me, the TL;DR was: - The main goal of writing code should be creating maintainable code with clear intent. - While unit testing is good, it is not a panacea for planning good architecture or system testing. - Good unit testing coverage will not spontaneously birth good architecture and at times it can even work against code clarity. - System testing is a better representation of how our code works - Unit testing should support our goals, and not become a goal in and of it self. I highly encourage everyone to carve out some time to watch. http://www.youtube.com/watch?v=9LfmrkyP81M -- Corey Floyd Software Engineer Mobile Apps / iOS Wikimedia Foundation

5 6

Content missing from mobile apps and mobile web
by Pine W 03 Apr '15

03 Apr '15

Hi mobile teams, Awhile ago I pointed out (https://phabricator.wikimedia.org/T91621) that the important template in content pages that directs readers from article subsections to "main articles" is missing from mobile web pages. I have since found other templates with relevant reader-oriented content to be missing from mobile web. With the latest Android app release this problem appears to be happing at greater scale in mobile apps now as well. For example the audio demonstration of jazz that I placed at the top of the "Jazz" article on English Wikipedia is missing from Android and from mobile web. Please, please __do not__ use technical means to delete content or templates from mobile views when they are intended for our readers on all platforms and were placed in articles through the efforts of volunteers, especially not without a community discussion first. Formatting tweaks are negotiable, but this kind of content elimination makes me upset. I feel that it degrades Wikipedia's value to readers, and as a person who adds audio and other templates to articles I find it discouraging to have my efforts removed from the view of so many Wikipedia readers. Thank you for your work to make Wikipedia reading be a good experience on mobile. Pine

8 13

[Apps] [iOS] XCActionBar
by Corey Floyd 02 Apr '15

02 Apr '15

So this is just absolutely amazing… https://github.com/pdcgomes/XCActionBar Install as fast as possible… -- Corey Floyd Software Engineer Mobile Apps / iOS Wikimedia Foundation

2 2

Wikimedia Apps Team at the Lyon Hackathon
by Adam Baso 02 Apr '15

02 Apr '15

Hello All, The Wikimedia Apps team will participate in the Wikimedia Hackathon 2015 in Lyon, France 23-25 May. We've setup a page to help promote the event and give a chance to link up with us. If you know people in France and nearby countries, we would be most thankful if you could spread the word. https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2015/Mobile_apps Thanks! -Adam

1 0

Consult about Wikitext's parser on Android-app
by cxyshine＠yeah.net 02 Apr '15

02 Apr '15

hi, Wikitext is a document written in a wiki markup language,and all the articles on mediaWiki are writen as Wikitext . and I have read the code of mediaWiki-android-app for some weeks , and i feel confused about how mediaWiki-android-app parse the Wikitext ,where is the code of Wikitext parser ? or it don't need to parse wikitext ,then how does the android-app show a wiki article to user ? I hope some can help Thanks Shine

2 2

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

Mobile-l April 2015