November 2014 - Mobile-l - lists.wikimedia.org

[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

Pulling the Commons app
by Derk-Jan Hartman 27 Nov '14

27 Nov '14

I propose we remove the Wikimedia Commons app from the store. Clearly there is no time available to work on it, there is no one maintaining it or following up on the problems that have been reported since 2013. Yann is just brining it up on wikimedia-l and I think that it is bad to have an app out there that no on is taking care of. So we should pull it and whoever wants to continue with it can release it under a name of this own. DJ

11 24

[Web+Apps] Introducing KPhab, our new bug migration system
by Dan Garry 26 Nov '14

26 Nov '14

Hi everyone, In light of the Phabricator migration, a few people in the Mobile Web and Mobile Apps teams met to discuss how we're going to handle this. In a meeting with Quim a few weeks ago, Mobile Web and Mobile Apps decided that the long term plan was to switch to Phabricator, but for now we're going to stick with Trello because Phabricator is missing a few bits of functionality that we really like. We communicated these so the team upstream is aware. For now, people will be filing issues with our products in Phabricator. So how do we get those into Trello? We may make Phabello, a tool to automatically import things using the Trello and Phabricator APIs, but that's not on the cards right at this moment. Here were our outcomes of how we're going to interact with Phabricator: - All engineering team members should make sure they're receiving information about bug escalations. Do this by clicking "Watch project" on the relevant projects on Phabricator: - Joaquin, Kaldari, Baha, Rob, Jon, Max, Sam, Maryana: MobileFrontend - Adam, Monte, Brion, Dan: iOS app <https://phabricator.wikimedia.org/tag/wikipedia-app-ios-app/> - Dmitry, Bernd, Dan: Android app <https://phabricator.wikimedia.org/project/view/489/> - Kristen will volunteer to serve as Phabello for now. Say hi to KPhab! The process will be: - Look at all new bugs entered since last standu - Enter those as cards in Trello: - Create card with same title as bug in Phabricator - Add link to Phabricator in the card description - Add link to Trello in the Phabricator bug, saying that the issue is tracked in Trello - Mark bug as "Normal" priority All hail KPhab! Dan -- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation

2 1

mdot webroot redirects on Wikipedia Zero
by Adam Baso 26 Nov '14

26 Nov '14

Hi, just wanted to give people a heads up about language-sensitive redirects on the m.wikipedia.org/ (and zero.wikipedia.org/) webroot: https://www.mediawiki.org/wiki/Wikipedia_Zero/Accept-Language_Aware_Redirec… Dan Foy, Maryana, and I spoke on this stuff, and we thought it would be best to see how this works in Wikipedia Zero land, and then if it works well, continue dialog for the mobile web Wikipedia webroot afterward for the non-Wikipedia Zero use case. Usually we don't like to vary the cache on Accept-Language, but this is one place where we're exploring the concept. It's possible to try to figure out the language prefix in Varnish, but for now we're trying this as a pure MediaWiki thing. -Adam

3 4

15 mil pr�mios, voc� ja ganho? PROGRAMA DE VANTAGENS CIELO S/A (11674)
by mobile-l＠lists.wikimedia.org 26 Nov '14

26 Nov '14

1 0

Re: [WikimediaMobile] [Wikitech-l] Open source mobile image recognition in Wikipedia
by Tomasz Finc 24 Nov '14

24 Nov '14

CC'ing mobile-l to let them know of this Exciting to see projects like this showing up. I do notice that it's not compatible with Nexus5, Nexus7, and a number of other standard devices. Looking at your manifest it should just work. Did you put in a Google Play restriction on which devices it works on? --tomasz On Mon, Nov 24, 2014 at 2:25 AM, Adrien Maglo <adrien(a)visualink.io> wrote: > Hello, > > > I am not sure this is the right mailing list to introduce this project but I > have just released Displee. It is a small Android app that allows to search > for images in the English Wikipedia by taking pictures: > https://play.google.com/store/apps/details?id=org.visualink.displee > It is a kind of open source Google Goggles for images from en.wikipedia.org. > > I have developed Displee as a demonstrator of Pastec http://pastec.io, my > open source image recognition index and search engine for mobile apps. > The index hosted on my server in France currently contains about 440 000 > images. They may not be the most relevant ones but this is a start. ;-) > I have also other ideas to improve this tiny app if it has an interest for > the community. > > Displee source code (MIT) is available here: > https://github.com/Visu4link/displee > Pastec source code (LGPL) is available here: > https://github.com/Visu4link/pastec > The source code of the Displee back-end is not released yet. It is basically > a python3 Django application. > > I will be glad to receive your feedback and answer any question! > > Best regards, > > > -- > Adrien Maglo > Pastec developer > http://www.pastec.io > +33 6 27 94 34 41 > > _______________________________________________ > Wikitech-l mailing list > Wikitech-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l

1 0

Update on QA resources assigned to Apps and Editing
by Dan Garry 24 Nov '14

24 Nov '14

Greg, James, Kristen, Rummana, Elena and myself met today to discuss our next steps for the QA resources assigned to Editing and Mobile Apps. We decided that both Elena and Rummana will split their time roughly 50% between Editing and Apps. As we agreed that QA should be integrated into the teams, Elena and Rummana will attend the standups and meetings of both teams. This will help ensure that both QA testers are aware of ongoing feature development and can allocate themselves accordingly. That said, we acknowledged that with any assignment of our very limited QA resources, there would be need to be some inherent flexibility. Perhaps the Editing Team needs more QA than normal one week due to a big release, and perhaps the Mobile Apps Team needs more in a different week. That flexibility is agreed going in, and we can evaluate that on a week-by-week basis. Although both testers will test for both Editing and Apps, there will be primary points of contact for QA in both teams to ensure continuity of communications: - Elena will be the primary point of contact in QA for Mobile Apps - Rummana will be the primary point of contact in QA for Editing Mobile Apps will continue to engage with The Specialists Guild for broad regression testing and testing of compatibility with different versions of the iOS and Android OS. The success of this arrangement will be reevaluated in early February, or sooner if deemed necessary. Thanks, Dan -- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation

2 2

[Web] Spike: Explore using CSSLint/LessLint in mobile
by Bahodir Mansurov 24 Nov '14

24 Nov '14

After reading benefits of CSSLint there is no doubt in my mind that we should use it. Here [1] are some of the benefits. They range from possible errors to compatibility to performance, etc. With grunt we can use grunt-lesslint [2], which employs CSSLint under the hood so we can also tweak it using CSSLint rules. What do you guys think? [1] https://github.com/CSSLint/csslint/wiki/Rules <https://github.com/CSSLint/csslint/wiki/Rules>. [2] https://github.com/jgable/grunt-lesslint <https://github.com/jgable/grunt-lesslint>

3 5

Chinese Wikipedia
by Jon Robson 24 Nov '14

24 Nov '14

I spoke to some Taiwanese students learning English (with help from a translator) about Wikipedia, Wikimedia and mobile. Age range was 17-35 so quite a mix. I was hoping I'd find some developers in the room but sadly no so I focused the talk around using the mobile site. Interestingly everyone here used Wikipedia, but when I asked them if they used the mobile site of Wikipedia they all said no. When I probed more I discovered "Google" was where they got their information. I managed to confirm that they were going to Wikipedia but most of them didn't realise. Some things I notice: * They actually were disappointed they couldn't upload images anymore. Most wanted to edit but didn't know how. Post wikigrok it would be interesting to see if we can use the saving mechanism there to queue up uploads to the site. * When I showed them Listen To Wikipedia they got really excited and registered straight away just to see their name. Interesting tactic we might want to explore for signups :) * They struggled with the captcha when registering (surprise surprise). It's English words not Chinese words. I notice everyone has WiFi passwords here that are numbers. It would be interesting to explore captchas that involve numbers if that is at all possible. * In the language overlay in 3 out of 3 cases where people have used it they all seemed to scroll down, no one realises they can search for the language at the top. That's a UX problem I guess we need to fix. * When they have flicked from Chinese to English Wikipedia and then use the search bar at the top of the page to search for information they type in chinese and expect search terms to show up there. * They didn't seem to recognise the hamburger as a menu icon * They asked to edit and surprise surprise I saw lots of templates in every example I tried. The keys to the templates are English e.g. in infoboxes. I think this makes a strong argument for being able to edit infoboxes from wikidata (I've got an example below). Today is my last day working remotely from China but I'm happy on my travels to do anymore Chinese research if you find this interesting and want to know more about potential Wikipedians here :) Example infobox: {{Taxobox | color = pink | name = 斑尾鹃鸠 | status = LC | status_system = iucn3.1 | image = MacropygiaUnchall.jpg | regnum = [[动物界]] Animalia | phylum = [[脊索动物门]] Chordata | classis = [[鸟纲]] Aves | ordo = [[鸽形目]] Columbiformes | familia = [[鸠鸽科]] Columbidae | genus = [[鹃鸠属]] ''Macropygia'' | species = '''斑尾鹃鸠 ''M. unchall''''' | binomial = ''Macropygia unchall'' | binomial_authority = (Wagler)<ref name='id2051'>{{cite web | url = http://www.bioinfo.cn/db05/BjdwSpecies.php?action=view&id=2051 | title = 斑尾鹃鸠 | work = 《中国动物物种编目数据库》 | publisher = 中国科学院微生物研究所 | author = 中国科学院动物研究所 | accessdate = 2009-04-04 }}</ref> }}

5 7

Fwd: [Web] Spike: Explore using CSSLint/LessLint in mobile
by Derk-Jan Hartman 24 Nov '14

24 Nov '14

I notice I accidentally only sent this to Joaquin. DJ ---------- Forwarded message ---------- From: Derk-Jan Hartman <d.j.hartman(a)gmail.com> Date: Fri, Nov 21, 2014 at 4:07 PM Subject: Re: [WikimediaMobile] [Web] Spike: Explore using CSSLint/LessLint in mobile To: Joaquin Oltra Hernandez <jhernandez(a)wikimedia.org> Ehm, I tried working with CSSLint several times and in my opinion it simply doesn't (yet) work at our scale. We have WAY too many overrides. It also horribly fails on anything that is not known to it yet (new browser specific properties or values) and it doesn't have 'comment' overrides to ignore warnings or errors (at least last time I checked). If you are starting from scratch it is great (I even contributed a few patches to it), but I found it horrible to work with (unlike JSHint) in real world practice where exceptions are simply the norm to make stuff work cross platform. If you want to use it, plan on spending quite a bit of time tweaking upstream. DJ On Fri, Nov 21, 2014 at 9:45 AM, Joaquin Oltra Hernandez < jhernandez(a)wikimedia.org> wrote: > CSS is a beast and any help is going to be useful. > > As Jon said, we probably need a longer spike/task to see if any other > teams are doing CSS linting and there are already conventions we can use, > and to determine what validation rules we want to use. > El 21/11/2014 2:53, "Jon Robson" <jrobson(a)wikimedia.org> escribió: > > Which rules would MobileFrontend be able to use from the start? >> Which rules might be controversial to adopt? >> >> >> On Fri, Nov 21, 2014 at 9:00 AM, Bahodir Mansurov >> <bmansurov(a)wikimedia.org> wrote: >> > After reading benefits of CSSLint there is no doubt in my mind that we >> > should use it. Here [1] are some of the benefits. They range from >> possible >> > errors to compatibility to performance, etc. With grunt we can use >> > grunt-lesslint [2], which employs CSSLint under the hood so we can also >> > tweak it using CSSLint rules. >> > >> > What do you guys think? >> > >> > [1] https://github.com/CSSLint/csslint/wiki/Rules. >> > [2] https://github.com/jgable/grunt-lesslint >> > >> > _______________________________________________ >> > Mobile-l mailing list >> > Mobile-l(a)lists.wikimedia.org >> > https://lists.wikimedia.org/mailman/listinfo/mobile-l >> > >> >> _______________________________________________ >> Mobile-l mailing list >> Mobile-l(a)lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/mobile-l >> > > _______________________________________________ > Mobile-l mailing list > Mobile-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mobile-l > >

1 0

Re: [WikimediaMobile] Using jsbeautify in MobileFrontend
by Jon Robson 21 Nov '14

21 Nov '14

+ mobile-l This is all useful feedback. That would be ideal if jscs had this capability but an interim solution would be good in the meantime. I think it's important to codify our coding conventions across the project. It will make it much easier for newbies to write code without having to worry about coding style. On Fri, Nov 21, 2014 at 11:19 PM, Krinkle <krinklemail(a)gmail.com> wrote: > Hi Jon, > > Just wanted to quickly share my ideas on code formatting. > > First off, as long as there are no side effects (e.g. normalising too much), > any tool will do in the mean-while and it's trivial to switch later on (e.g. > just change which tasks the "grunt fixup" alias will run). They wouldn't be > run as part of "grunt test". Instead it's a convenience tool for developers > to easily reformat code locally before submission (e.g. after jscs pointed > out one or more errors in their local grunt run). This is among the reasons > why using a local Grunt is so convenient. It enables individual projects to > try out new tools without requiring server-side configuration. I try out new > tasks all the time in oojs-core and VisualEditor. Some stick, some don't. > > Having said that, I've used js-beautifier in the past and worry it won't > work well for us. > > esformatter[1] on the other hand seems to have a more stable implementation > and general approach. > > However, any tool other than jscs will come with the down side of having to > declare your style guide, again. Which will amount to tedious duplication > and loads of edge cases where the tools declare the style using different > logical rules and will never match. > > jscs ships with a wikimedia preset that saves lots of configuration in the > first place. > > And fortunately, jscs actually plans to ship an "autofixer" utility that > will correct violations from within jscs itself. Using the solid parser and > tokeniser that jscs is known for. Thus, even the small jscs rule config we > do have, won't have to be duplicated. > > The jQuery Team also supports this effort for their various javascript > projects (both as style checker, as we do already, and as code formatter). > So that's a major player we'll have on our side when it comes to continued > support for the tool. > > https://github.com/jscs-dev/node-jscs/issues/516 > > Supported by Mike Sherov (mikesherov) and Oleg Gaidarenko (markelog), from > the jQuery Team (who are also jscs collaborators). And Marat Dulin > (mdevils), founder of jscs. > > Best, > > — Krinkle > > [1] https://github.com/millermedeiros/esformatter > > On 20 Nov 2014, at 23:57, Derk-Jan Hartman <d.j.hartman(a)gmail.com> wrote: > > Begin forwarded message: > > Date: 20 november 2014 21:19:24 CET > From: Jon Robson <jrobson(a)wikimedia.org> > To: Bahodir Mansurov <bmansurov(a)wikimedia.org> > Cc: mobile-l <mobile-l(a)lists.wikimedia.org> > Subject: Re: [WikimediaMobile] Using jsbeautify in MobileFrontend > > Follow up > If I run `make jsbeautify` now > then https://gist.github.com/jdlrobson/a05ddad00175ebceac68 is the result. > > Outstanding actions: > * Need input on rest of the team about which of delete > this.cache[title]; or delete this.cache[ title ]; is the preferred > standard. > * You'll notice jsbeautify and inlne comments need to be ironed out. > For example: > https://gist.github.com/jdlrobson/a05ddad00175ebceac68#file-gistfile1-diff-… > > Apart from the above 2 jsbeautify makes some adjustments to our > whitspace which I guess we'll just have to live with. > > Please can everyone else let me know how they think we should proceed? > > > > On Wed, Nov 19, 2014 at 4:12 AM, Bahodir Mansurov > <bmansurov(a)wikimedia.org> wrote: > > As for # Rule 4, it makes sense to add spaces inside square brackets. The > reasoning is the same as why we add spaces inside parenthesis. > > On Nov 18, 2014, at 12:28 PM, Jon Robson <jrobson(a)wikimedia.org> wrote: > > I explored running jsbeautify [1] on the MobileFrontend codebase and > looked at how the output differs from the current styling. It > introduces various rules that MobileFrontend is currently not adhering > too. MobileFrontend already uses jscs [2] so we want to make sure the > outputs of both are compatible. Here is my report on that with the > recommendation that we should use it. > > #Rule 1: object properties defined on a single line. > e.g. > { > foo: 2, > bar: 3 > } > NOT { foo: 2, bar: 3 } > > I think this would be a good idea to adopt. I will explore if jscs can > enforce this. > > # Rule 2: variables that are initialised must be followed by a new > line (although I noted a few odd cases e.g. in Page.js after a "?:" > expression and /MobileWebClickTracking.js > e.g. > var Foo, bar = $( 'div' ), > Baz, > Bar; > > not: > var Foo, bar = $( 'div' ), Baz, Bar; > > This will be fixed if I implement https://trello.com/c/0dkx0ldL > > # Rule 3: All chained events should be indented > e.g. > foo() > .bar(); > > not > foo(). > bar(); > > Seems like a no brainer. One that happens naturally most of the time. > > # Rule 4: Spacing in object parameters > e.g. > foo[ 1 ] > [ 1, 2, 3, 4 ] > > not: > foo[1] > [1, 2, 3, 4] > > This is different to MediaWiki coding conventions but I can implement > https://github.com/beautify-web/js-beautify/issues/424 to give us > this. > We seem a bit inconsistent ourselves with this convention - let me > know how you think this rule should work in our codebase... > > # Rule 5: New line after variable declarations > > var x, y, z; > > z(); > > not: > var x, y, z; > z(); > > Also: > function foo() {} > > function bar() {} > > not: > function foo() {} > function bar() {} > > Seems like a no brainer and shouldn't introduce any major issues with > code review. > > # Rule 6: Comments must respect the current indentation level > > if () { > ... > // If i is 5 we do something special > } else if ( i === 5 ){ > > } > becomes > if () { > ... > // If i is 5 we do something special > } else if ( i === 5 ){ > > } > We'll have to think about what to do with these comments but I don't > think this should be a blocker to using jsbeautify. It will only pop > up occasionally. > > # Rule 7: On long if statements the curly brace must be indented. > And the first condition should be on the same line > > if ( enableToc || ... > .... > && baz ) { > > > not: > if ( > enableToc || ... > .... > && baz ) { > > Again I'm not sure if this will happen too often. This to me is a sign > that we should be using functions rather than long if statements > personally. Again not a blocker. > > Actions: > * Implement https://github.com/beautify-web/js-beautify/issues/424 > * You guys need to advise me on how we should handle square brackets > in our codebase in such a way we respect MediaWiki coding conventions > and come up with a consistent style we are happy with and can adhere > to. > * I'll implement https://trello.com/c/0dkx0ldL in some form > * I'll explore if jscs can support objects defined on new line > * When the above are done I recommend we turn on jsbeautify for the project. > > I've setup a tracking card for the above work: > https://trello.com/c/5btWf2JN/90-snakes-on-a-plane > and will be looking at these problems today. > > [1] https://github.com/beautify-web/js-beautify > [2] https://github.com/jscs-dev/node-jscs > > _______________________________________________ > Mobile-l mailing list > Mobile-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mobile-l > > > > _______________________________________________ > Mobile-l mailing list > Mobile-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/mobile-l > > >

3 4

21 Nov '14

In the course of examining Opera Mini bugs, I've been talking with Jared and Maryana and others about different types of browser feature support, and I needed to run some queries to get a handle on the facts. Results follow. Prologue: I ran some queries to gauge <noscript> (no JavaScript support at all) usage, versus usage of browsers with low-end JavaScript ("ResourceLoader-impaired", or for short, "RLI") precluding them from things like mobile editing, on the mobile web Wikipedias. I thought I'd share this information with you. Caveat Emptor: I am not a Ph.D in maths/stats. And I haven't had the queries peer reviewed. But I've tried to analyze each OR case for User-Agent in the queries below to ensure that I actually see results that are sensible. Results: On zero-rated networks accessing mobile web Wikipedia:* About 1.8% of Wikipedia Zero banners served are to <noscript> browsers. The other 98.2% of banners are served to browsers with at least some form of JavaScript support.* About 36% of Wikipedia Zero pageviews (using a dumbed down definition) are on RLI browsers. On non-zero-rated networks accessing mobile web Wikipedia:* The percentage of users on <noscript> browsers is unknown (AFAIK) but if we implemented a <noscript> tracking pixel akin to the GIF banner on Wikipedia Zero, I suspect we'd find it's 1.8% or less.* About 6% of overall Wikipedia mobile web pageviews (using a dumbed down definition) are on RLI browsers. Even gorier details. SQL/HQL at the end: 1. When browsers request GIF Wikipedia Zero banners, the URL has zcmd=img-banner in it. When they request JavaScript banners, the URL has zcmd=js-banner in it. Both banners have a cache lifetime of 300 seconds, so it's roughly apples to apples when we look at their usage. 2. The simplest definition of a pageview I've found useful is to look at HTTP 200 (non-cached) HTML responses and JSON responses for well defined URL paths. 3. Our ResourceLoader bootstrapping code at https://git.wikimedia.org/blob/mediawiki%2Fcore.git/09c55592a73544cc21e002f… , which puts things like Opera Mini in the RLI bucket, also puts Google Glass in the RLI bucket. That doesn't mean Google Glass is incapable of running high end JavaScript, it just reflects that the screen is really small. Just wanted to point that out. Expansion into wearables and IoT will be a theme I'm sure in due time. 4. The other approximately 62% or approximately 92% of user agents for zero-rated networks and non-zero-rated networks, respectively, in the non-RLI buckets may in fact lack good JavaScript facilities and we just don't know any better (actually, we know for a fact at least some have bad JS support), but these are rough figures, after all. 5. Some of the traffic is definitely from bots and the like, but I didn't want to overcomplicate these queries any further. On the upside, In the overall scheme of non-zero-rated mobile web Wikipedia access, bot traffic such as GoogleBot kind of gets washed out because of the large number of pageviews. Bot traffic on Wikipedia Zero networks seems to be fairly low grade at the moment. 6. The queries. These queries could be optimized, but I erred on the side of clarity, if you can call it that, for people familiar with SQL/HQL. If we were to explore this more, I might also be interested in tuning the non-Opera Mini browsers that are still Opera but are at too low of a version; these non-OM Opera browsers might be slightly undercounted. It may be the case that the particular two OR cases for the existing queries is getting those particular rows with sufficient accuracy as is. Single day requests for GIF Banners on zero-rated networks:74,807 (1.8% of total) select count(*)from webrequestwhere uri_host like '%.wikipedia.org'and uri_query like '%zcmd=img-banner'and year = 2014 and month = 11 and day = 19and webrequest_source = 'mobile'and x_analytics like '%zero=%'; Single day requests for JavaScript Banners on zero-rated networks:4,100,385 (98.2% of total) select count(*)from webrequestwhere uri_host like '%.wikipedia.org'and uri_query like '%zcmd=js-banner'and year = 2014 and month = 11 and day = 19and webrequest_source = 'mobile'and x_analytics like '%zero=%'; Single day zero-rated "dumbed down" pageviews on Wikipedia mobile web, expressly ResourceLoader-impaired UAs:1,099,607 (36% of total) select count(*)from webrequestwhere year = 2014and month = 11and day = 19and webrequest_source = 'mobile'and uri_host like '%.wikipedia.org'and http_status = '200' and(content_type like '%text/html%' or content_type like '%application/json%')and (uri_path like '/wiki/%' or uri_path like '/w/index.php' or(uri_path like '/w/api.php%' and uri_query like '%action=mobileview%'))and (coalesce(regexp_extract(user_agent, '(MSIE *[0-7][^\\d])', 1), '') != ''or coalesce(regexp_extract(user_agent, '(Firefox\\/ *[0-2][^\\d])', 1), '') != ''or(user_agent like '%Opera/%'and user_agent not like '%Version/%'and coalesce(regexp_extract(user_agent, '(Opera\\/[0-9][^\\d])', 1), '') != '')or(user_agent like '%Opera/%'and user_agent like '%Version/%'and coalesce(regexp_extract(user_agent, '(Version\\/(11|10|[0-9])[^\\d])', 1), '') != '')or coalesce(regexp_extract(user_agent, '( Opera *[0-9][^\\d])', 1), '') != ''or coalesce(regexp_extract(user_agent, '(BlackBerry[^\\/]*\\/[1-5]\\.)', 1), '') != ''or coalesce(regexp_extract(user_agent, '(webOS\\/1\\.[0-4])', 1), '') != ''or lower(user_agent) like '%playstation%'or user_agent like '%SymbianOS%'or user_agent like '%Series60%'or user_agent like '%NetFront%'or user_agent like '%Opera Mini%'or user_agent like '%S40OviBrowser%'or (user_agent like '%Glass%' and user_agent like '%Android%'))and x_analytics like '%zero=%'; Single day zero-rated "dumbed down" pageviews on Wikipedia mobile web, all UAs:3,047,700 (100% of total) select count(*)from webrequestwhere year = 2014and month = 11and day = 19and webrequest_source = 'mobile'and uri_host like '%.wikipedia.org'and http_status = '200' and(content_type like '%text/html%' or content_type like '%application/json%')and (uri_path like '/wiki/%' or uri_path like '/w/index.php' or(uri_path like '/w/api.php%' and uri_query like '%action=mobileview%'))and x_analytics like '%zero=%'; Single day "dumbed down" pageviews on Wikipedia mobile web (includes both zero-rated and non-zero-rated), expressly ResourceLoader-impaired UAs:12,152,389 (6% of total) select count(*)from webrequestwhere year = 2014and month = 11and day = 19and webrequest_source = 'mobile'and uri_host like '%.wikipedia.org'and http_status = '200' and(content_type like '%text/html%' or content_type like '%application/json%')and (uri_path like '/wiki/%' or uri_path like '/w/index.php' or(uri_path like '/w/api.php%' and uri_query like '%action=mobileview%'))and (coalesce(regexp_extract(user_agent, '(MSIE *[0-7][^\\d])', 1), '') != ''or coalesce(regexp_extract(user_agent, '(Firefox\\/ *[0-2][^\\d])', 1), '') != ''or(user_agent like '%Opera/%'and user_agent not like '%Version/%'and coalesce(regexp_extract(user_agent, '(Opera\\/[0-9][^\\d])', 1), '') != '')or(user_agent like '%Opera/%'and user_agent like '%Version/%'and coalesce(regexp_extract(user_agent, '(Version\\/(11|10|[0-9])[^\\d])', 1), '') != '')or coalesce(regexp_extract(user_agent, '( Opera *[0-9][^\\d])', 1), '') != ''or coalesce(regexp_extract(user_agent, '(BlackBerry[^\\/]*\\/[1-5]\\.)', 1), '') != ''or coalesce(regexp_extract(user_agent, '(webOS\\/1\\.[0-4])', 1), '') != ''or lower(user_agent) like '%playstation%'or user_agent like '%SymbianOS%'or user_agent like '%Series60%'or user_agent like '%NetFront%'or user_agent like '%Opera Mini%'or user_agent like '%S40OviBrowser%'or (user_agent like '%Glass%' and user_agent like '%Android%')); Single day "dumbed down" pageviews on Wikipedia mobile web (includes both zero-rated and non-zero-rated), all UAs:199,764,072 (100% of total) select count(*)from webrequestwhere year = 2014and month = 11and day = 19and webrequest_source = 'mobile'and uri_host like '%.wikipedia.org'and http_status = '200' and(content_type like '%text/html%' or content_type like '%application/json%')and (uri_path like '/wiki/%' or uri_path like '/w/index.php' or(uri_path like '/w/api.php%' and uri_query like '%action=mobileview%'));

1 0

Update on ResourceLoader-constrained UAs
by Adam Baso 21 Nov '14

21 Nov '14

Hi there - A lot of people on Wikipedia Zero use browsers ("User Agents", or "UAs" for short) incompatible with site JavaScript [1]. We want to ensure that critical functionality is basically functional for these people, and we've been tracking findings at https://etherpad.wikimedia.org/p/Lower_end_devices_checkup. Thus far, we've re-reviewed Search [2] and Login/Account Creation [3], and we'll be going over the other ones over the next several sprints. I just added some screenshots from Opera Mini to the two Trello cards below. To replicate Opera Mini behavior for oneself, if you don't already have it, you can install Opera Mini on a device like an Android or iOS device. Then set the app's mode to "Opera Mini" mode. Depending on your OS, you may or may not need to toggle this "Opera Mini" setting; it might be on by default. You can also use the emulator as described on the Wikipedia Zero tech page [4]. -Adam [1] https://git.wikimedia.org/blob/mediawiki%2Fcore.git/09c55592a73544cc21e002f… This shows JavaScript UAs for which it's known that the JavaScript capabilities are likely insufficient for a number of JavaScript features, and thus the ResourceLoader technology instructs the UA to not commence with further JavaScript loading. There are also other UAs with no JavaScript support or with broken JavaScript implementations. [2] https://trello.com/c/blWoHdk8/1-improve-special-search-for-lower-end-device… Incidentally, there's currently a regression making it impossible to enter searches, at least on the Android and iOS Opera Mini clients I tested. [3] https://trello.com/c/0kKBcmoD/2-improve-login-and-account-creation-experien… Note: On non-HTML5 browsers, the "placeholder" attribute is not supported. [4] https://www.mediawiki.org/wiki/Wikipedia_Zero#Tools

3 5

Using jsbeautify in MobileFrontend
by Jon Robson 21 Nov '14

21 Nov '14

I explored running jsbeautify [1] on the MobileFrontend codebase and looked at how the output differs from the current styling. It introduces various rules that MobileFrontend is currently not adhering too. MobileFrontend already uses jscs [2] so we want to make sure the outputs of both are compatible. Here is my report on that with the recommendation that we should use it. #Rule 1: object properties defined on a single line. e.g. { foo: 2, bar: 3 } NOT { foo: 2, bar: 3 } I think this would be a good idea to adopt. I will explore if jscs can enforce this. # Rule 2: variables that are initialised must be followed by a new line (although I noted a few odd cases e.g. in Page.js after a "?:" expression and /MobileWebClickTracking.js e.g. var Foo, bar = $( 'div' ), Baz, Bar; not: var Foo, bar = $( 'div' ), Baz, Bar; This will be fixed if I implement https://trello.com/c/0dkx0ldL # Rule 3: All chained events should be indented e.g. foo() .bar(); not foo(). bar(); Seems like a no brainer. One that happens naturally most of the time. # Rule 4: Spacing in object parameters e.g. foo[ 1 ] [ 1, 2, 3, 4 ] not: foo[1] [1, 2, 3, 4] This is different to MediaWiki coding conventions but I can implement https://github.com/beautify-web/js-beautify/issues/424 to give us this. We seem a bit inconsistent ourselves with this convention - let me know how you think this rule should work in our codebase... # Rule 5: New line after variable declarations var x, y, z; z(); not: var x, y, z; z(); Also: function foo() {} function bar() {} not: function foo() {} function bar() {} Seems like a no brainer and shouldn't introduce any major issues with code review. # Rule 6: Comments must respect the current indentation level if () { ... // If i is 5 we do something special } else if ( i === 5 ){ } becomes if () { ... // If i is 5 we do something special } else if ( i === 5 ){ } We'll have to think about what to do with these comments but I don't think this should be a blocker to using jsbeautify. It will only pop up occasionally. # Rule 7: On long if statements the curly brace must be indented. And the first condition should be on the same line if ( enableToc || ... .... && baz ) { not: if ( enableToc || ... .... && baz ) { Again I'm not sure if this will happen too often. This to me is a sign that we should be using functions rather than long if statements personally. Again not a blocker. Actions: * Implement https://github.com/beautify-web/js-beautify/issues/424 * You guys need to advise me on how we should handle square brackets in our codebase in such a way we respect MediaWiki coding conventions and come up with a consistent style we are happy with and can adhere to. * I'll implement https://trello.com/c/0dkx0ldL in some form * I'll explore if jscs can support objects defined on new line * When the above are done I recommend we turn on jsbeautify for the project. I've setup a tracking card for the above work: https://trello.com/c/5btWf2JN/90-snakes-on-a-plane and will be looking at these problems today. [1] https://github.com/beautify-web/js-beautify [2] https://github.com/jscs-dev/node-jscs

4 8

(no subject)
by Monika 21 Nov '14

21 Nov '14

Sent from Samsung Mobile

1 0

Material Design Icons
by Bernd Sitzmann 20 Nov '14

20 Nov '14

Google has uploaded the Material Design icons to Github.[1] At a quick glance it seems to have all the icons we need, and already in svg format. There's even a toc icon[2]. I think we should consider switching to those for the Android app to be more in line with other Android apps. Bernd [1] https://github.com/google/material-design-icons [2] https://github.com/google/material-design-icons/blob/master/action/svg/prod…

1 0

Did something change about prefix search today?
by Monte Hurd 20 Nov '14

20 Nov '14

Here's what searching for "fish" returned yesterday: And here's what I get today:

5 9

switching languages
by Amir E. Aharoni 18 Nov '14

18 Nov '14

Hi, I am raising this issue every once in a while... Is there any plan to make the app less monolingual? See https://bugzilla.wikimedia.org/show_bug.cgi?id=34100 Currently, the app shows content only in one language. It's possible to switch to another language according to the interlanguage link, but the searching will always be in one language until changed in the preference. Back when the feedback mailing list was active this was one of the most requrested features, and I personally strongly support it. At the very least, searching must work in the language of the currently displayed article, because seeing content in one language and searching in another is badly confusing. Better yet, there should be a way to define several "favorite languages" in which the user is interested, and to show search results from all of them. Any chance of that happening soon? -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com ‪“We're living in pieces, I want to live in peace.” – T. Moore‬

5 4

translatable messages in betas
by Amir E. Aharoni 18 Nov '14

18 Nov '14

Hi, A friendly reminder: please add all new translatable messages to the source and commit them to Gerrit as early as possible, so that translators will get a chance to translate them before betas are released. In the world or Wikimedia / translatewiki localization we strongly believe that releasing translatable strings as early as possible makes the whole process of translating and testing much more efficient and prevents bugs such as https://bugzilla.wikimedia.org/show_bug.cgi?id=72607 Thank you! :) -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com ‪“We're living in pieces, I want to live in peace.” – T. Moore‬

2 4

Server-side face detection
by Dmitry Brant 18 Nov '14

18 Nov '14

Just throwing this out there: Would it be possible to have a script that crawls through images on Commons, detects faces in the images, and embeds the x,y position of the face(s) into the File page of the image (or into the Exif data of the image) (and makes this information available via the API)? For a little context -- in our mobile apps, we'll be featuring images related to the article that the user is browsing; however, the way that we're cropping the images sometimes has the side effect of cropping out the face of the subject (when the face is far from the center of the image). Even though we can do face detection locally on the user's device, it can be a bit slow and a bit intensive. It would be great if this task was offloaded, and the face position was returned right along with the image itself... -Dmitry

4 6

availability of apps beta installation instructions
by Amir E. Aharoni 15 Nov '14

15 Nov '14

Hi, I am testing the beta apps for both Android and iOS. If I recall correctly, I got the installation instruction for them by email. I wanted to suggest testing them to somebody, but I couldn't find convenient instructions for doing this. I'd expect to find them somewhere on https://www.mediawiki.org/wiki/Wikimedia_Apps or on https://www.mediawiki.org/wiki/Mobile , or by searching "ios app beta" on mediawiki.org, but I couldn't find anything. Can these be posted in some convenient place at mediawiki.org, please? Thanks! -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com ‪“We're living in pieces, I want to live in peace.” – T. Moore‬

3 5

Last modified graph weirdness
by Jon Robson 14 Nov '14

14 Nov '14

According to http://mobile-reportcard.wmflabs.org/graphs/ui-daily on Thursday 23rd October (deployment day) both last modified links to history and profile suffered a huge dip in clicks. The dip seems to half both counts, which makes me theorize that we were accidentally logging clicks here twice. The microtap code got merged on Tue Oct 14 so would have gone out to mediawiki.org 16th and then enwiki 23rd and caused a lot of issues so could be responsible for this too.. If this is responsible, does this mean we made these 2 links unclickable for half our audience or did we simply just fail to log events for these 2 features? Or were we logging two events for a single event? Note, micro tap was reverted Thu Nov 6. I'm not sure if and when this revert made it out to wikis. I'm not sure if we can expect the graph to recover or stay plateaued. Any more concrete ideas/theories? Were there any notable code changes around that time to this part of code?

1 1

Review needed for mobile video overlay (native and ogv.js playback)
by Brion Vibber 12 Nov '14

12 Nov '14

I've gotten some great review feedback from Gilles on the desktop-web integration of my ogv.js JavaScript & Flash compatibility layers for Ogg Theora/Vorbis media files -- thanks Gilles! * libraries: https://gerrit.wikimedia.org/r/#/c/165477/ * desktop integration: https://gerrit.wikimedia.org/r/#/c/165478/ These are getting pretty close to ready to land, I think. I would love to get some review on the mobile overlay I've whipped up as well. This supports both native WebM playback (Android Chrome, Android Firefox, Firefox OS) and ogv.js playback (iOS 7/8 Safari). * mobile overlay: https://gerrit.wikimedia.org/r/#/c/165479/ * Live demo: https://ogvjs-testing.wmflabs.org/ A few open questions: 1) Is this the right way to do mobile overlay code? (It's basically a rip of the existing photo viewer overlay in MobileFrontend, but lives in TimedMediaHandler.) Is the overlay interface stable enough for other extensions to use it for mobile-specific features? (I had to make updates for object-model and template things that changed since this summer.) 2) Is the inline icon too huge/ugly here for audio files? Should it be arranged differently, or display the player inline instead of as an overlay for audio? 3) Should more controls be added to the overlay's bottom toolbar, such as manual resolution selection or an 'Open in VLC' link to support HD playback on iOS? 4) Should we autoplay when opening the overlay, or require a second tap? 5) How should we handle devices with no native playback that are either too slow (iOS 6 Safari) or lack necessary features needed for the player (Windows Phone)? Current known bugs in the mobile overlay: * CPU speed check not yet integrated to force to lowest resolution for old iPhones/iPads (this exists on the desktop integration, just needs to be moved to common code) * autoplay doesn't seem to work with native playback right now -- brion

4 11

Android app Alpha builds working again
by Bernd Sitzmann 08 Nov '14

08 Nov '14

The Android app Alpha builds[1] are working again. Note that the alpha builds are based on the latest code that got merged, so they should be considered less stable than the beta or production releases, of course. Cheers, Bernd [1] AaA: https://android-builds.wmflabs.org/

1 0

[Apps] Material design
by Dan Garry 08 Nov '14

08 Nov '14

As you know, Vibha and I went to the material design conference today at Google San Francisco. In short, I'm sold. Material design, hoo! I took longer form notes in an etherpad <http://etherpad.wikimedia.org/p/MaterialDesignConference>, but here's the long and short of it in the form of four principles: 1. *Tangible surfaces:* Your phone is not a view port into an alternate world. The UI of your app should feel tangible, like little bits of paper moving around the screen. 2. *Print-like design: *UI elements should be like print on paper. Use a consistent hierarchy for your information. 3. *Meaningful motion: *UI panels should never come out of nowhere; the motion and interaction conveys how everything you're looking at is connected together. 4. *Adaptive design: *Having a consistent UI across devices of all size does not mean making everything have the same layout. I realise this all sounds very high level, but it resonated with me quite a lot. Google has even incorporated these principles into their apps on iOS, such as Google Maps which is now using material design! I'm currently trying to find the exact presentation that was shown today, but in the mean time you can look at this for more info: http://www.google.com/design/spec/material-design/introduction.html More to come! Dan -- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation

1 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

Mobile-l November 2014