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

Browser support for MobileFrontend
by Juliusz Gonera 12 Jun '14

12 Jun '14

Since our support table for browsers [1] is wildly out of date, we should come up with something better. Oliver generated some statistics for us from the last 30 days from logs for text/html requests (see attachment). I think we could divide browsers into Grade A and Grade B categories, similarly to desktop. Grade A would be full support, Grade B would be basic support for reading (non-JS version). Two additional suggestions: * Don't care about anything below < 0.1% * Drop support for JS for any problematic browser with < 0.5% (mark them as Grade B) I think coming up with a generic metric like "support last N versions of X and last M versions of Y" for all browsers would be hard because the browser landscape changes pretty fast. I'd rather reevaluate our support table every few months. For now, I propose the following: Grade A: * Mobile Safari 5-7 (that includes Chrome for iOS since it uses Safari's engine) * Android Browser 2.3+ (drop 2.3 to grade B as soon as it's < 0.5%) * Chrome for Android 18+ * Firefox for Android, latest version (since it's not very popular, but still a good browser) * IE Mobile 9+ (drop 9 to grade B as soon as it's < 0.5%) * Blackberry Webkit 7+ Grade B: * lower versions of browsers in Grade A * Opera Mini 4+ * NetFront 3+ * Ovi Browser 2+ * Nokia Browser 7+ When it comes to Grade B browsers, I don't think we should test on them very regularly, but accept bugs that come from their users. Comments? [1] https://www.mediawiki.org/wiki/Browser_support#Mobile_browsers -- Juliusz

5 11

Browser tests coverage in MobileFrontend stable (Result of spike 1687)
by Jon Robson 12 Jun '14

12 Jun '14

I ran an audit of the existing browser tests for MobileFrontend as part of a mobile team spike [1]. You can see the results here: https://www.mediawiki.org/wiki/Mobile/QA_Test_Audit_March_2014 Our coverage is actually not too bad, but there is definitely room from improvement. That said I have a big concern is around the organisation of the tests and how they are written and what is written - many of the tests could do with being reworded and a lot of them should probably actually be deleted. There is a lot of code duplication. When auditing I found tests scattered all over the place. This suggests that we could benefit from reorganising the file structure to be more logical, in particular features that relate to special pages should have their own folder (this is particularly useful for clarifying what tests the watch star and what tests the actual watchlist page - Zeljko / Chris is it possible to have subfolders in the features directory that contain features?). I would also suggest the following actions for improving our test coverage: * Add tests for error handling on login / account creation * Add tests for this page has issues * Improve tests for key editing and upload workflows * Add tests for Language variant support * Add tests for full text search support * Improve the existing watch star tests so they actually check the end result * Add test to check the user can close the left navigation menu * Add tests for logout * Add tests for reference overlay * Add tests for toggling * Add tests for Nearby in skins other than Minerva (mobile skin) * Address hygiene issues on https://www.mediawiki.org/wiki/Mobile/QA_Test_Audit_March_2014 [1] https://wikimedia.mingle.thoughtworks.com/projects/mobile/cards/1687

3 5

QQQuestion
by Monte Hurd 31 May '14

31 May '14

Is there a standard way to indicate in a qqq file that a particular translation should try to be as few characters as possible?

3 2

Fwd: [Wikimedia-l] Mobile Operator IP Drift Tracking and Remediation
by Adam Baso 30 May '14

30 May '14

FYI ---------- Forwarded message ---------- From: Adam Baso <abaso(a)wikimedia.org> Date: Fri, May 30, 2014 at 2:04 PM Subject: Re: [Wikimedia-l] Mobile Operator IP Drift Tracking and Remediation To: Wikimedia Mailing List <wikimedia-l(a)lists.wikimedia.org> Okay, the code is in place in the alphas of both the Android and iOS apps, and the server-side 2% sampling (extra header in HTTPS request sent once per cellular app session) is working. https://git.wikimedia.org/commitdiff/apps%2Fandroid%2Fwikipedia.git/8b4a0c3… https://git.wikimedia.org/commitdiff/apps%2Fios%2Fwikipedia.git/59cde497921… https://git.wikimedia.org/commitdiff/mediawiki%2Fextensions%2FZeroRatedMobi… Changes to event logging in the iOS alpha app (internal only at the moment, although repo can be cloned and run in the Xcode simulator) are coming pretty soon, and once those are in, we'll make one last tweak there to have the app not add the extra MCC/MNC header on that single request per cellular connection when logging is turned off in the iOS alpha app. That part is done in the Android app already. -Adam On Fri, May 2, 2014 at 1:16 PM, Adam Baso <abaso(a)wikimedia.org> wrote: > Federico asked if sampling might make sense here. I think it will work, so > I've updated the patchset. > > From a patchset comment I provided: > > "It's possible we may have situations where operators have not lots of > users on them accessing Wiki(m|p)edia properties, so we do run some risk of > actually missing IPs, even if exit IPs are concentrators of typically large > sets of users. That said, let's try a 2% sample ratio; and if we find out > it's insufficient, then we'll sample more, if it's oversampling, then we > can adjust the other way, too. New patchset arriving shortly." > > (I've since submitted the updated code for review.) > > -Adam > > > > On Thu, May 1, 2014 at 7:52 PM, Adam Baso <abaso(a)wikimedia.org> wrote: > >> After examining this, it looks like EventLogging is more suited to the >> logging task than debug logging and the trappings of needing to alter debug >> logging in the core MediaWiki software. >> >> EventLogging logs at the resolution of a second (instead of a day), but >> has inbuilt support for record removal after 90 days. >> >> Please do let us know in case of further questions. Here's the logging >> schema for those with an interest: >> >> https://meta.wikimedia.org/wiki/Schema:MobileOperatorCode >> >> Here's the relevant server code: >> >> https://gerrit.wikimedia.org/r/#/c/130991/ >> >> -Adam >> >> >> >> >> On Wed, Apr 16, 2014 at 2:20 PM, Adam Baso <abaso(a)wikimedia.org> wrote: >> >>> Great idea! >>> >>> Anyone on the list know if there's a way to make the debug log >>> facilities do the YYYYMMDD timestamp instead of the longer one? >>> >>> If not, I suppose we could work to update the core MediaWiki code. [1] >>> >>> -Adam >>> >>> 1. For those with PHP skills or equivalent, I'm referring to >>> https://git.wikimedia.org/blob/mediawiki%2Fcore.git/a26687e81532def3faba646…. >>> Scroll to the bottom of the function definition to see the datetimestamp >>> approach. >>> >>> >>> On Wed, Apr 16, 2014 at 12:47 PM, Andrew Gray <andrew.gray(a)dunelm.org.uk >>> > wrote: >>> >>>> Hi Adam, >>>> >>>> One thought: you don't really need the date/time data at any detailed >>>> resolution, do you? If what you're wanting it for is to track major >>>> changes ("last month it all switched to this IP") and to purge old >>>> data ("delete anything older than 10 March"), you could simply log day >>>> rather than datetime. >>>> >>>> enwiki / 127.0.0.1 / 123.45 / 2014-04-16:1245.45 >>>> >>>> enwiki / 127.0.0.1 / 123.45 / 2014-04-16 >>>> >>>> - the latter gives you the data you need while making it a lot harder >>>> to do any kind of close user-identification. >>>> >>>> Andrew. >>>> On 16 Apr 2014 19:17, "Adam Baso" <abaso(a)wikimedia.org> wrote: >>>> >>>> > Inline. >>>> > >>>> > Thanks for starting this thread. >>>> > > >>>> > > Sorry if I've overlooked this, but who/what will have access to this >>>> > data? >>>> > > Only members of the mobile team? Local project CheckUsers? Wikimedia >>>> > > Foundation-approved researchers? Wikimedia shell users? AbuseFilter >>>> > > filters? >>>> > > >>>> > >>>> > It's a good question. The thought is to put it in the customary >>>> wfDebugLog >>>> > location (with, for example, filename "mccmnc.log") on fluorine. >>>> > >>>> > It just occurred to me that the wiki name (e.g., "enwiki"), but not >>>> the >>>> > full URL, gets logged additionally as part of the wfDebugLog call; to >>>> make >>>> > the implicit explicit, wfDebugLog adds a datetime stamp as well, and >>>> that's >>>> > useful for purging old records. I'll forward this email to mobile-l >>>> and >>>> > wikitech-l to underscore this. >>>> > >>>> > >>>> > > And this may be a silly question, but is there a reasonable means of >>>> > > approximating how identifying these two data points alone are? That >>>> is, >>>> > > Using a mobile country code and exit IP address, is it possible to >>>> > > identify a particular editor or reader? Or perhaps rephrased, is >>>> this >>>> > data >>>> > > considered anonymized? >>>> > > >>>> > >>>> > Not a silly question. My approximation is these tuples (datetime, now >>>> that >>>> > it hit me - XYwiki, exit IP, and MCC-MNC) alone, although not >>>> perfectly >>>> > anonymized, are low identifying (that is, indirect inferences on the >>>> data >>>> > in isolation are unlikely, but technically possible, through >>>> examination of >>>> > short tail outliers in a cluster analysis where such readers/editors >>>> exist >>>> > in the short tail outliers sets), in contrast to regular web access >>>> logs >>>> > (where direct inferences are easy). >>>> > >>>> > Thanks. I'll forward this along now. >>>> > >>>> > -Adam >>>> > _______________________________________________ >>>> > Wikimedia-l mailing list >>>> > 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 >>>> Wikimedia-l(a)lists.wikimedia.org >>>> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, >>>> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe> >>>> >>> >>> >> >

1 0

New Android Alpha release
by Bernd Sitzmann 30 May '14

30 May '14

We have an updated alpha version of the Android app available on the Play Store. If you'd like to opt in to get automatic updates of the alpha version, please follow these instructions:http://lists.wikimedia.org/pipermail/mobile-l/2014-March/00664… What's new in this release: - Newer styles. Stop using OpenSans, switch back to default font. - Not showing the edit screen for pages that the user cannot edit anymore. Bernd

1 0

Mobile App Retrospective notes are up on the wiki
by Tomasz Finc 30 May '14

30 May '14

The Mobile App team had their monthly retrospective yesterday. Notes, further discussion, and action items are below. https://www.mediawiki.org/wiki/Wikimedia_Apps/imported/Retrospective-May_30… Extra thanks to Kaldari, Juliusz, Max, and others for their help with mobile web style re-use. = Further discussion items = * 80/20 Rule. Would like to think about behaviors for us instead of traditional patterns +1.++++ [Vibha] * Would be great to have automated builds ++ [Bernd - Android, Brion - iOS] * Need more ios testers! [monte] * Who 'target user' is++++ [Dan] * Continued/detailed testing with Android 2.3/3/4/etc? (+1 +1 +1)+ [Dmitry] * iOS market release unclear++++ [Dan] * Developer and Product standpoint on standard vs custom [Vibha] Thanks team and all involved. --tomasz

1 0

App Alphas - Wikipedia Zero Features Screencasts
by Adam Baso 29 May '14

29 May '14

Colleagues in UX are looking for opportunities to add final polish for Wikipedia Zero related stuff in the forthcoming apps, but here are screencasts for the Wikipedia Zero experience in the alphas of the apps. Android: https://drive.google.com/file/d/0BxJX28FKLm78bmcyOEtzVkUyYlU/edit?usp=shari… iOS: https://drive.google.com/file/d/0BxJX28FKLm78blZLX0UwRHNCSms/edit?usp=shari… The Android screencast is a little clunkier because I was using tethering and shooting from the same device to get things working and so had to string some videos together. iOS is a little less clunky because, although I also needed to use tethering, I was recording with a simulator. -Adam

1 0

Android app typography changes
by Moiz Syed 29 May '14

29 May '14

Just had a meeting with Yuvi and we decided that we should keep the fonts consistent on android app with android mobile web for the time being, and not introducing another font (Open Sans) in the mix. The changes will take a few minutes of work, and Yuvi has already made a card for it on trello. The changes include keeping page styling consistent with mobile web on android using Roboto for text and using Roboto for app chrome typography too.

5 7

Re: [WikimediaMobile] A card for Reference display?
by Tomasz Finc 28 May '14

28 May '14

Moving to mobile-l@ --tomasz On Wed, Apr 9, 2014 at 10:29 AM, Kenan Wang <kwang(a)wikimedia.org> wrote: > Is this necessary for MVP? I'm concerned about our ability to hit our dates > and scope creep. > > > On Wed, Apr 9, 2014 at 10:12 AM, May Tee-Galloway <mgalloway(a)wikimedia.org> > wrote: >> >> On the design side, since Kaity is working on reference-related projects, >> she'll be helping me iterate from what I've done here. >> >> >> On Wed, Apr 9, 2014 at 10:04 AM, Yuvi Panda <yuvipanda(a)wikimedia.org> >> wrote: >>> >>> I just looked over our cards for the next sprint and backlog and realized >>> we have nothing for handling how references are displayed. Kenan can you add >>> a card to the appropriate location? >> >> > > > > -- > > Kenan Wang > Product Manager, Mobile > Wikimedia Foundation

4 3

svg images in bad position on mobile view
by Aaron Schneider 28 May '14

28 May '14

Bug sent: Bug 65856 - Chess picture in mobile view not displayed properly https://bugzilla.wikimedia.org/show_bug.cgi?id=65856

1 0

[spike] Determine where the performance problems are with VE
by Jon Robson 27 May '14

27 May '14

I was tasked with investigating why on large pages, mobile takes longer to load a page then VE. To do this I loaded a template heavy page in both mobile and desktop and ran JavaScript profiling on both. In desktop7.9% of time was spent in jQuery.extend.css - this was the most heavy function. In mobile it was also the most heavy - however in mobile a whopping 23.76% of time was spent in jQuery.extend.css In mobile 14360 calls were made to by both desktop and mobile to get the value of float. Looking closer at what was calling these I found it was related to phantom element. So it looks like fixing the following bug: https://bugzilla.wikimedia.org/show_bug.cgi?id=64709 will help improve performance in mobile drastically. I imagine the slowdown is related to the fact that on desktop existing content is replaced with VisualEditor interface but on mobile there are more DOM elements as VisualEditor is opened in an overlay on top of the content. Specifically the calls inside this callback that hog the most are: 1) $this.css( 'float' ); 2) node.$.context.importNode( $shieldTemplate[0], true )

9 19

Test failures -> Trello: Introducing Sellello
by Jon Robson 27 May '14

27 May '14

A new tool to add to the Bingle and Bugello family - introduce Selello Selello checks the state of RSS feeds published by Jenkins relating to failed browser tests e.g. this one for MobileFrontend[1] When a browser test has been failing for a considerable time e.g. for the last 3 builds it will post a card to Trello. No card will be posted on the 4th or 5th time the tests fail. An output card can be found here: https://trello.com/c/BFoSR3XY/58-firefox-build-575-failing-selenium-tests e.g. It will only post a card if 1) The current build is failing 2) The last build to pass was over 3 runs ago. I'm hoping this will be a better alert mechanism than the current notification emails. Please help me get this reviewed and up and running! [2] [1] https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs… [2] https://github.com/wikimedia/bingle/pull/38

3 3

VisualEditor broken on mobile
by Jon Robson 27 May '14

27 May '14

According to our tests, VisualEditor is broken. It seems to be another targets issue We should get this fixed ASAP Card: https://trello.com/c/w2MNCzTP/69-chrome-build-461-failing-selenium-tests Bug: https://bugzilla.wikimedia.org/show_bug.cgi?id=65823

3 3

[Apps] Blockers for sign-off
by Dan Garry 23 May '14

23 May '14

Hey everyone, I've done all of the sign off that I can. There's quite a few cards left in the sign-off column, so I'm going to explain why each one's been left there and what's blocking us from moving forwards. Each card is linked to in the first sentence. *Browsing controls <https://trello.com/c/BOEUXAM6/5-1-as-a-user-i-would-like-browsing-controls-…> *and *search <https://trello.com/c/CPYeJAkM/21-3-as-a-user-i-can-search-from-the-top-chro…>:* I think the new browsing controls and search look fantastic! I'd like the designers to double-check the card and app to make sure they're happy with it too (I've CCd them in case they're not on this list). If they're happy, we can sign off on it. I have one minor niggle with search (documented on the card), but I think it's okay to solve that after the first release. *CSS resources <https://trello.com/c/Bei6hEaD/40-3-point-the-apps-to-online-extension-mobil…>:* I'm unclear what the user-facing aspect of this is, so I don't know how to sign off. Yuvi (or anyone else), can you offer clarification? *Don't auto-clear history <https://trello.com/c/4UW2MZ9v/62-don-t-clear-history-items-after-30-days>: *This one is awkward to test because it relies on both the app *not* doing something, and also it not doing it after 30 days have elapsed! I'm unsure how to sign off on it. Advice, devs? Everything else is signed off. Thanks guys! Dan -- Dan Garry Associate Product Manager for Platform and Mobile Apps Wikimedia Foundation

2 6

Showing the number of talk topics on the article page
by Jon Robson 23 May '14

23 May '14

In the alpha mode of mobile we show a number inside the talk icon that shows how many open talk topics there are on a page. For example here: On the San Francisco [1] page you see a 7. If you click it there are 7 topics / sections. The code has been stagnating for some time, which is a real shame in my opinion as it surfaces the talk page and discussions more. It works by generating a number of sections on each save and storing them in a page property to avoid performance implications. I personally find it very intriguing when I see a high discussion count on what seems like a non-controversial topic. e.g. Tofu has 37 open topics and makes me curious to click on it and read what people have been discussing around it [2] It's hard to measure the impact of the talk bubble when it is displayed like this. I'd be interested to do some sort of A/B test around it to see whether more people visit the talk page when the number is shown - I'm not sure if Growth has any plans to do this. Also I wonder if this is something Flow is thinking about. Either way can we make a decision and either kill this code, or bring it into beta mode? [1] https://en.m.wikipedia.org/wiki/San_Francisco?mobileaction=alpha [2] https://en.m.wikipedia.org/wiki/Tofu?mobileaction=alpha

4 4

Kill dynamic page views?
by Max Semenik 23 May '14

23 May '14

No, seriously. It had been in alpha since forever, we routinely spend our precious time on fixing bugs in it but it never was usable enough even for promotion to beta. Let's not waste resources on it and kill it. -- Best regards, Max Semenik ([[User:MaxSem]])

2 1

Re: [WikimediaMobile] [Design] Showing the number of talk topics on the article page
by Jon Robson 23 May '14

23 May '14

> Then people would avoid starting a talk page when the number is 0. This is, in my view, a bad thing. This is a valid assumption and one we could test. A zero might even prompt new discussions. We'll never know unless we explore it. I'm just curious if there are any plans to test this and other similar hypotheses. > This number would have to be generated by MediaWiki or Flow, but surely not by MobileFrontEnd. As I said, MobileFrontEnd is only a skin. Not true. MobileFrontend has a few more bits of code that make it a little more than a skin - e.g. special pages like Special:Nearby. It currently records this number via a hook and is agnostic to Flow and MediaWiki (although this code could easily be added to MediaWiki core to be standardised)

4 3

Image Quality on the Mobile Web
by Adam Baso 23 May '14

23 May '14

Heads up: The MediaWiki core change https://gerrit.wikimedia.org/r/#/c/119661/ for https://www.mediawiki.org/wiki/Requests_for_comment/Reducing_image_quality_… being rolled out. The next step we think is to rewrite the <img> tags on a popular page (e.g., http://en.m.wikipedia.org/wiki/Cats) when Wikipedia Zero is in force in order to give this a run in production. We'll share findings once a patch is written and implemented taking advantage of the image quality URL rewriting capability. -Adam

2 1

Re: [WikimediaMobile] [Design] Showing the number of talk topics on the article page
by Jon Robson 23 May '14

23 May '14

"Unless you find a use-case which you're addressing, don't code this please." We coding this over a year ago on this basis but nothing has been done with it. My question that I am wondering if we should explore the answer to is: "Does showing the number of talk topics on an article increase engagement in discussions?" (Note evidence from many user tests that have been run in the past 2 years give me the impression that many non-editors are not aware there is a discussion side to Wikipedia) "It is. There is no need to code things twice - as mobile interface is merely a skin." I'm not sure what you mean here. The mobile team has been thinking about doing this, this doesn't mean Flow has been. I'm not sure what skins have to do with anything here. Yes Flow could easily surface such a number but the number would have to be generated and surfaced somewhere since Flow is implemented completely differently. On Fri, May 23, 2014 at 2:47 PM, Gryllida <gryllida(a)fastmail.fm> wrote: > Hi, > > On Fri, 23 May 2014, at 21:44, Jon Robson wrote: >> In the alpha mode of mobile we show a number inside the talk icon that >> shows how many open talk topics there are on a page. >> >> For example here: >> On the San Francisco [1] page you see a 7. If you click it there are 7 >> topics / sections. > > Horrendous task. I'd use a talk icon instead - the count never matters. The only case is when I care whether there is 0 or not, so I know whether it's worth skimming anything against my concern or I should start a new topic. > > Unless you find a use-case which you're addressing, don't code this please. > >> Also I wonder if this is something Flow is thinking about. > > It is. There is no need to code things twice - as mobile interface is merely a skin. > > Gryllida. > > _______________________________________________ > Design mailing list > Design(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/design

3 3

Question about Table of Contents
by Jon Robson 22 May '14

22 May '14

Pages without first headings or 2nd headings will show a table of contents at the end of the page. Maryana what would you advise doing in this situation? Since we are pushing this to stable it's probably worth making a call on how to treat this: https://bugzilla.wikimedia.org/show_bug.cgi?id=60478 (a third option is do nothing - although it seems weird having a table of contents at the end of the page :-))

2 1

World of pain getting use existing references
by Jon Robson 22 May '14

22 May '14

I've been away from OOUI/VisualEditor codebase for some time and I'm hitting my head against a wall trying to get anywhere with what seems like a small task. Firstly I'm having issues getting citations working at all on my vagrant instance - http://imgur.com/WZmEWXj is how they look when I load VE despite looking like http://imgur.com/dGA3sLw before I hit edit. (I gave up trying to develop this on my local instance) That aside, I figured I could easily add a 'reference' command to the bottom of the menu that would load the ReferencesDialog which contains the 'use existing reference' button. I figured it would be good to make this button open the ReferenceDialog and then explore a way of refactoring that so that 'use existing reference' could be used outside it or at the very least a reference dialogue could be opened and straight away switched to use existing reference. With this quest defined, I went into the code to work out how to do this. I looked at ve.ui.MWReferenceDialog.js and got the command name 'reference' and added it to the list like so: 'include': [ { 'group': 'cite' }, 'reference' ] Magically a button appeared so i got excited and clicked it, hoping I would see a reference dialog of some kind. Sadly this caused things to explode, and I'm unable to debug this in any coherent fashion to work this out. I've now been stuck for the past 2 hours and since I'm on GMT hours I've been unable to find help on irc. I'm turning to you guys to work out how I can take this further or if I'm going down the wrong rabbit hole. Help needed. I see Juliusz is on IRC so I'm hoping he'll be able to help.

2 3

micro-contributions on mobile via wikidata
by Ryan Kaldari 22 May '14

22 May '14

Check out http://tools.wmflabs.org/wikidata-game/ Most of these "games" would be great in a mobile context. Ryan Kaldari

3 3

Notes on mobile instrumentation needs
by Dario Taraborelli 21 May '14

21 May '14

This is a summary of my discussion with Maryana on mobile instrumentation needs: Registration tagging The ServerSideAccountCreation log only knows about mobile vs desktop registrations. Down the line we should modify it to tag new accounts by source {desktop, mobile web, mobile app, other}. For now, we can just use the existing log and extract the source by combining the userAgent and displayMobile fields. There are comments on the Schema:MobileWikiAppCreateAccount talk page that require feedback from the mobile team, if we intend to use this log for signups on apps. Revision tagging We propose the creation of a new “app” tag in MediaWiki on top of the current “mobile edit” tag, which we will keep for backward-compatibility. This will give us an easy way of counting all mobile edits combined or app-only edits. Detailed breakdown of edit volume/quality by app platform or version will be done via EventLogging instrumentation. App instrumentation Platform-specific logs such as Schema:MobileWikiAppEdit are an ok interim solution but we should revamp the original plans for a consolidated edit funnel instrumentation to be able to compare edit funnel events across different platforms and interfaces. Given that this data is not product/feature specific, it’s likely an Analytics responsibility to implement it. Tablet edits We still don’t have a consistent way of identifying and counting edits made on tablets (on our desktop or mobile site), but we can get some initial estimates by using UA data from the last 30 days. Mobile dashboards We will review the existing mobile dashboards to figure out which ones should be eventually migrated to Vital Signs. Dario

2 1

Some interesting data in a couple of the Limn graphs
by Jon Robson 21 May '14

21 May '14

According to http://mobile-reportcard.wmflabs.org/graphs/ui-daily clicks to the home page in the left navigation menu have been dropping since Thursday 1st May. On Mon Apr 21 a search bar was put at the top of all search pages. This would have hit mediawiki.org late Thursday 24th and then all wikis by Thursday 1st May. This suggests that most people were visiting the home link as a way to get back to the search bar, so this seems like it has been a successful move. The history link has proved popular and lots of people are clicking on it. The user profile link is also proving popular. Special:MobileOptions is interesting to look at Looking at the graph it seems a lot of people visit the options page and enter beta mode or disable images http://mobile-reportcard.wmflabs.org/graphs/mobile-options The fact the lines follow a simple trend suggests that opting into beta and turning off images are done at the same time in many of these cases. I wonder how many of these people actually wanted to turn off images and how many people were just playing around?

2 1

[Apps] User testing results
by Dan Garry 21 May '14

21 May '14

Hey everyone. Last night I did some user testing of the editing workflow on both the Android and iOS apps. I had four new users and one experienced editor participating. The test was that I gave people the app on [[Main Page]] on testwiki, and said "There's an error on the bird article. Can you go and fix it?". The full unabridged notes I took are available on this etherpad<http://etherpad.wikimedia.org/p/AppUserTesting>, but here's my summary. 1. *Search: *Most people know straight away where the search bar is and what it does, although the actual functionality on iOS is a little clunky. 2. *Editing: *Everyone immediately knew that the pencil icon would let them edit. They all knew how to fix the typo, and that they should press the save icon afterwards to save. 3. *Preview: *In response to the preview, two of the four new users said "I'm done!" and handed the device back to me, unaware that their edit hadn't saved and they were only looking at a preview. The one experienced editor also expected it to save rather than present her with a preview, but she recognised that it was a preview. 4. *Edit summary box: *Three of the four new users missed the edit summary box. When I pointed it out to them, one said to me "I wish when I pressed save, it had told me to fill in the edit summary box". The experienced editor found the suggested edit summaries in iOS incredibly confusing, but when I pointed out the edit summary box to the new users they found them really helpful. 5. *Call to action to sign in and save: *The immediate reaction of all four new users to the CTA was to press "Save anonymously", with them not even reading the text to explain the difference. Only the experienced editor wanted to sign in and save. I've got to dash to a meeting, so I'll follow-up later with what I think the take-home messages are. Thanks! Dan -- Dan Garry Associate Product Manager for Platform and Mobile Apps Wikimedia Foundation

1 0

Namespacing MF?
by Max Semenik 20 May '14

20 May '14

We already have a bunch of classes with names prefixed with 'MF', 'Mobile' or even 'MobileFrontend' - maybe it's time to finally put all our stuff into a namespace and simplify a lot of names? -- Best regards, Max Semenik ([[User:MaxSem]])

3 2

[Apps] Dan doing user testing!
by Dan Garry 20 May '14

20 May '14

I'm doing some user testing for the apps, mostly on new users but also on one experienced editor. See me do my usertesting live on this etherpad: http://etherpad.wikimedia.org/p/AppUserTesting Dan -- Dan Garry Associate Product Manager for Platform and Mobile Apps Wikimedia Foundation

1 0

Re: [WikimediaMobile] instructions for getting citations working in VE
by Jon Robson 19 May '14

19 May '14

I finally got this working by also copying http://pastebin.com/FsK7TBZ9 into Template:Cite_book Forwarding to mobile-l in case it helps anyone else. I used vagrant [1] which made this a lot easier after a failed attempt on my local instance. [1] https://www.mediawiki.org/wiki/MediaWiki-Vagrant On Fri, May 16, 2014 at 2:08 AM, Ryan Kaldari <rkaldari(a)wikimedia.org> wrote: > Hey Jon, > There are two ways you can get citations working locally. Apparently there > is a Vagrant config you can use, or you can set it up manually: > 1. Install the TemplateData extension and set it up according to the > installation instructions on Mediawiki.org > 2. Install the Scribunto extension and set it up according to the > installation instructions on Mediawiki.org > 3. Copy the main citation module from en.wiki to your local wiki: > https://en.wikipedia.org/wiki/Module:Citation/CS1 > 4. Create some citation templates. The easiest way to do this is to copy the > code from en.wiki, but delete everything in the noinclude sections > (otherwise you'll be in template dependancy hell) > 5. Add templateData data to your template pages. See the TemplateData > documentation on Mediawiki.org > 6. Set up your cite group definition on your local wiki at > MediaWiki:Visualeditor-cite-tool-definition.json, for example: > [ > { "name": "web", "icon": "ref-cite-web", "template": "Cite web" }, > { "name": "book", "icon": "ref-cite-book", "template": "Cite book" }, > { "name": "news", "icon": "ref-cite-news", "template": "Cite news" }, > { "name": "journal", "icon": "ref-cite-journal", "template": "Cite > journal" } > ] > > Good luck! > > Ryan -- Jon Robson * http://jonrobson.me.uk * https://www.facebook.com/jonrobson * @rakugojon

2 1

Separate tags for Apps and Web?
by Dan Garry 19 May '14

19 May '14

Hey everyone, Howie and I were chatting today about the users we're expecting on Apps. We suspect that the nature of the app will attract a different user base from Web and perhaps also Desktop, and that may mean we need to tailor the features that go into the app to that user base. We'd like some data to test that hypothesis Right now the tagging system just tags all edits are made on mobile, and there's no way to distinguish between apps and web. We'd like to change that. Splitting the tags would allow us to identify users that edit just on apps and figure out if they are actually different. All in all, there's potential for creating some really awesome data to analyse. My preferred solution is for us to have three tags for Mobile: Mobile Web, iOS App, and Android app. That way, we can generate usage statistics really easily for both iOS and Android independently of each other, and also compare those to each other. There is also the possibility of tagging all edits as mobile using the current tag, then additionally tagging edits as iOS and Android respectively. That makes the numbers between Web and Apps harder to compare, so I prefer the first option. Thoughts, guys? Thanks, Dan -- Dan Garry Associate Product Manager for Platform and Mobile Apps Wikimedia Foundation

5 5

Auto clearing reading history in the Android app
by Yuvi Panda 19 May '14

19 May '14

Hello! The Android App has a 'Reading History' feature that is akin to browsing history on browsers. It lists the pages you have read and allows you to go back to them in the future. It is stored only on your device, and not sent anywhere. There was a 'feature' that cleared out old history items after 30 days. From talking to users this was unexpected and inconsistent with what they would expect from browsing history. Since there is a clear all button, they expect the history to stay till they explicitly clear all of it. I've prepared a patch https://gerrit.wikimedia.org/r/#/c/133966/ that strips this feature out and makes it behave more in line with user expectations. These records don't take up too much space anyway, so it should have minimal impact. -- Yuvi Panda T http://yuvi.in/blog

2 1

Update on Wikipedia App release timeline
by Maryana Pinchuk 16 May '14

16 May '14

Hi everyone, The Mobile Apps team just met and discussed the timeline for the release of the new Android & iOS Wikipedia apps. We've decided to descope a bit and decouple the two platforms from each other. Our first release will be an *Android beta app on June 4th*, and our end-of-fiscal-year goal is shipping the *fully fledged Android app on June 25th. *We'll still be working on the iOS app, but it won't be released to market until next fiscal year (e.g., July). We're biting off an ambitious chunk of work in our MVP of the retooled apps (improving the reading experience, adding an editing workflow, supporting Zero users), and doing all of this for both platforms with a small (but, luckily, swiftly growing!) team, while maintaining consistent design/UX and leveraging platform-specific capabilities has been tough. There are a number of deciding factors in making the choice to focus on shipping to Android first, including: * We currently have more Android engineers than iOS, so we can move faster on that end. * Android users are a slightly higher percentage of our total current app users.[1] * Android is more critical for the Wikipedia Zero program. * The Android release process is faster and easier for pushing out small bug-fixes, which we'll almost certainly need to do a lot of as soon as we put anything out there in front of a wide audience. * iOS comes with higher user expectations on the UI/UX side, and we need a bit more time to ensure our product meets those expectations. We'll probably want to mention some of this in external-facing communication about the new app and the release, since the Global North app market is still pretty iOS-centric and people might want to know why we're not targeting that audience first :) If you have any questions or concerns, please let me know. And I'll be in touch with Comms to continue the discussion on communication strategy -- we'll probably want some social media attention to announce the beta release & get more beta testers excited about getting their hands on the app! 1. https://meta.wikimedia.org/wiki/File:2014-05-01_Mobile_Metrics.pdf -- Maryana Pinchuk Product Manager, Wikimedia Foundation wikimediafoundation.org

1 0

Commons picture-of-the-day background changer for Android
by Luis Villa 15 May '14

15 May '14

FYI that someone has written a plugin for Muzei (a popular minimalist background switching app on Android) that switches your background among random recent Commons Picture of the Days every few hours. I've really enjoyed seeing a variety of beautiful Commons-y things on my phone since I've started using it; so I thought I might share here. Code: https://github.com/ebraminio/WikimediaCommonsForMuzei You can get it through F-Droid: https://f-droid.org/repository/browse/?fdid=org.wikimedia.commons.muzei Muzei, the parent app, which is really quite simple and beautiful itself- a nice model in what a pleasant-to-use Android app can be: https://play.google.com/store/apps/details?id=net.nurik.roman.muzei FYI- Luis

2 1

Fwd: [Wikidata-l] Edit Item Suggestions
by Erik Moeller 15 May '14

15 May '14

If you didn't see this at the hackathon, check it out - with actual editing functionality, it would make a great mobile app :) ---------- Forwarded message ---------- From: Finke, Moritz <Moritz.Finke(a)student.hpi.uni-potsdam.de> Date: Sun, May 11, 2014 at 5:38 AM Subject: [Wikidata-l] Edit Item Suggestions To: "wikidata-l(a)lists.wikimedia.org" <wikidata-l(a)lists.wikimedia.org> Cc: BP2013N2 <BP2013N2(a)hpi.uni-potsdam.de>, "daniel(a)barooney.de" <daniel(a)barooney.de> Hi everyone, we would like all of you to try out a new website we created: The site finds Wikidata-Items, that are most likely missing certain properties. So just go there, select a property of your choice and see what items could profit from it. Item-Suggestions that are no longer relevant (because some of you followed the link and edited them ;) ) will be removed automatically in a timely manner. Btw we already plan on making it possible to edit the suggested items directly from the page. Link to the site: https://suggester.wmflabs.org/EditItemSuggestions/public Interesting Examples for some inspiration: Items that are missing "official language": http://suggester.wmflabs.org/EditItemSuggestions/public/?id=P37 Items that are missing "date of birth": http://suggester.wmflabs.org/EditItemSuggestions/public/?id=P569 Items that are missing "headquarters location": http://suggester.wmflabs.org/EditItemSuggestions/public/?id=P159 Item that are missing "record label": http://suggester.wmflabs.org/EditItemSuggestions/public/?id=P264 The underlying algorithm for finding the items is based on concepts/ideas described here: https://github.com/Wikidata-lib/Wikidata.lib/wiki/Intelligent-Forms#2-sugge… We hope you have fun and are looking forward to your feedback. Cheers Daniel Baron, Christian Dullweber, Moritz Finke _______________________________________________ Wikidata-l mailing list Wikidata-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation

2 1

New Android app alpha release out!
by Yuvi Panda 14 May '14

14 May '14

Hello! Just pushed a new release to the play store. Changelog: - Potential fix for a oft-repeated crashing bug (IllegalStateException) Do try it out! -- Yuvi Panda T http://yuvi.in/blog

1 0

Re: [WikimediaMobile] MobileFrontend-en.m.wikipedia.beta.wmflabs.org-linux-firefox - Build # 558 - Still Failing!
by Jon Robson 14 May '14

14 May '14

Bah... the fix Chris posted yesterday [1] has now led to this test on Firefox failing. Again not sure why - the element is there! I can see it! Chris any ideas about this one? [1] https://gerrit.wikimedia.org/r/133168 On Wed, May 14, 2014 at 2:49 AM, <jenkins-no-reply(a)cloudbees.com> wrote: > * FAILURE: MobileFrontend-en.m.wikipedia.beta.wmflabs.org-linux-firefox > Build #558 > <https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs…> > (Wed, 14 May 2014 00:06:27 +0000)* > *Test Result*<https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs…> > 1 failed, 0 skipped > Failed Tests *Test Name**Duration**Age* Special:Uploads > uploads.Upload image file<https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs…>28 > sec1<https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs…> All > Tests *Package**Duration**Fail**Skip**Total* (root)<https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs…>32 > min1089 >

1 0

Output from Zurich Hackathon - yet another maps extension!
by Jon Robson 13 May '14

13 May '14

During the Zurich hackathon, DJ Hartman, Aude and I knocked up a generic maps prototype extension [1]. We have noticed that many maps like extensions keep popping up and believed it was time we standardised on one that all these extensions could use so we share data better. We took a look at all the existing use cases and tried to imagine what such an extension would look like that wouldn't be too tied into a specific use case. The extension we came up with was a map extension that introduces a Map namespace where data for the map is stored in raw GeoJSON and can be edited via a JavaScript map editor interface. It also allows the inclusion of maps in wiki articles via a map template. Dan Andreescu also created a similar visualisation namespace which may want to be folded into this as a map could be seen as a visualisation. I invite Dan to comment on this with further details :-)! I'd be interested in people's thoughts around this extension. In particular I'd be interested in the answer to the question "For my usecase A what would the WikiMaps extension have to support for me to use it". Thanks for your involvement in this discussion. Let's finally get a maps extension up on a wikimedia box! Jon [1] https://github.com/jdlrobson/WikiMaps

1 0

[Apps] Sprint 31 begins: iOS redesign and Android bugs.
by Dan Garry 13 May '14

13 May '14

Greetings! I'm Dan, and I'll be your Product Owner for this product. Please keep your arms and legs inside the sprint at all times, and please be sure to read the sprint safety instructions stored in /dev/null. :-) As mentioned last week, the next two sprints will be split by platform. This sprint, iOS will have its design overhauled and we'll work on Android bugs. Next sprint, we'll flip things, and Android will be have the design overhaul and we'll work on iOS bugs. Our wonderful designers have provided us with more finalised mockups for the iOS redesign. They're available here: Mockup 1<https://trello-attachments.s3.amazonaws.com/52e98a603e6d08a53861025b/530e4b…> , Mockup 2<https://trello-attachments.s3.amazonaws.com/52e98a603e6d08a53861025b/52e98c…> . Let's get to work! Let me know if you've got any questions. Thanks, Dan -- Dan Garry Associate Product Manager for Platform and Mobile Apps Wikimedia Foundation

1 1

Fwd: Chrome test has been failing for some time
by Chris McMahon 13 May '14

13 May '14

On Tue, May 13, 2014 at 1:22 PM, Jon Robson <jrobson(a)wikimedia.org> wrote: > Thanks for documenting this Chris! > > I'm not sure if this should be a bug - maybe uploads to > Special:Uploads of this form should show an error message saying "We > already have this photo." ? > I am tempted to leave it the way it is and just have the test check the alt text of the thumbnail image rather than the href value. That would validate that the steps to upload are working properly. > > That aside how can we ensure each of the images uploaded is unique? > This test should be testing the case where an upload is unique.. I tried running this test using the shared image upload code to upload unique(ish) images. But doing that shows a modal dialog that says "Warning! This photo looks suspicious. If it's not a photo that you took, please do not upload it. Do you still want to continue?" I also get that modal dialog uploading images manually. We could make the test dismiss the modal dialog, but it would be better if we did not see the modal dialog at all. -Chris

2 2

Chrome test has been failing for some time
by Jon Robson 13 May '14

13 May '14

Chris, this test has been failing for some time and I can't quite work out why. In Chrome, it looks like uploaded_image_link always points to the upload link at the top of the page when it is loaded. I suspect Chrome driver matches the selector at the start and then doesn't refresh it to point to the latest element after the upload has completed. Either that or something funky is going on with the random string in Chrome. Chris or someone who knows this stuff could you take a look? I've spent the last hour trying to work it out to no avail... On Tue, May 13, 2014 at 7:12 AM, <jenkins-no-reply(a)cloudbees.com> wrote: > * FAILURE: MobileFrontend-en.m.wikipedia.beta.wmflabs.org-linux-chrome > Build #441 > <https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs…> > (Tue, 13 May 2014 04:36:29 +0000)* > *Test Result*<https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs…> > 1 failed, 0 skipped > Failed Tests *Test Name**Duration**Age* Special:Uploads > uploads.Upload image file<https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs…>31 > sec13<https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs…> All > Tests *Package**Duration**Fail**Skip**Total* (root)<https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs…>27 > min1081 >

2 4

Sprint 31 is estimated and ready to go
by Tomasz Finc 12 May '14

12 May '14

Heads up that last week we ended up estimating sprint 31. Mailing here for completeness. https://trello.com/b/BW5L3PEn/mobile-app-sprint-31-main-article-browse-sear… Android engineers notice that most of the stories in the sprint are *not* estimated as they are bugs and thus a drag on velocity. This was the team norm we adopted many months ago. It'll be especially noticeable this sprint as we have a ton of defects to fix on Android. Let me know if you have any questions especially if you're traveling --tomasz

1 0

[Apps] Bugzilla component rearrangement
by Dan Garry 12 May '14

12 May '14

(This email was originally sent six days ago Dmitry, Brion, Yuvi and Monte. I'm forwarding to mobile-l for broader coverage) Hey guys, There's a proposal to reorganise the Wikipedia Apps product in Bugzilla to make it slightly more intuitive. Yuvi's proposed that we change the components from being a mix of both platform and version (e.g. "Android (alpha)") to just platform (e.g. "Android"), then changing the versions bit to Alpha, Beta, and Stable. That'd allow us to better configure Bugzilla with default CC lists. Yuvi's proposed change is documented here: https://bugzilla.wikimedia.org/show_bug.cgi?id=64621#c3. We're planning on going ahead with this in a few days, but if any of you have objections, please do comment on the bug and we can find a solution that works for everyone. Thanks, Dan -- Dan Garry Associate Product Manager for Platform and Mobile Apps Wikimedia Foundation

1 0

Invitation for participation in DigitalSec2014-Ostrava, Czech Republic
by International Conference on Digital Security and Forensics (DigitalSec2014) 11 May '14

11 May '14

CALL FOR PAPERS The International Conference on Digital Security and Forensics (DigitalSec2014) June 24-26, 2014 VSB-Technical University of Ostrava Ostrava, Czech Republic http://sdiwc.net/conferences/2014/digitsec2014/ ----------------------------------------------------------- The proposed conference on the above theme will be held at VSB-Technical University of Ostrava, Ostrava, Czech Republic From June 24-26, 2014. All papers will be published in the proceedings of the conference, sDIWC digital library and best papers for special issue journals. Important Dates: ================ Final Submission Deadline : May 25, 2014 Notification of Acceptance: 7 days from the submission date Camera Ready : June 14, 2014 Registration : June 14, 2014 Conference Dates : June 24-26, 2014

1 0

Re: [WikimediaMobile] Nearby
by Jon Robson 11 May '14

11 May '14

I'm adding mobile-l to this as I think it is a useful discussion. The plan is to move the nearby code into the Geodata extension. To do this however we must remove the dependency on MobileFrontend code which is not an easy. Check out the Mantle extension. This isn't final but it will give you an idea of a potential plan of action. This patch [1] will also give you an idea of how we could do this. [1] https://gerrit.wikimedia.org/r/129480 On 27 Apr 2014 23:58, "Prateek Saxena" <psaxena(a)wikimedia.org> wrote: > Should we consider moving Nearby out of MobileFrontend and into its > own extension? > > -prtksxna >

5 7

Re: [WikimediaMobile] Nearby
by Jon Robson 11 May '14

11 May '14

The only issue is a scaling issue. Due to the traffic such a service would create we need to be able to support our own tile server and have a team that manages it. There is a bug around this. No legal issues as far as I'm concerned... https://bugzilla.wikimedia.org/show_bug.cgi?id=33980 On 10 May 2014 22:04, "Prateek Saxena" <psaxena(a)wikimedia.org> wrote: On Sun, May 11, 2014 at 12:56 AM, Russell Nelson <russnelson(a)gmail.com> wrote: > I just read the whole Nearby card. Why is "OSM privacy situation is a bit of > a mess?" I don't know about legal stuff, CC'd Luis to clarify. On Sun, May 11, 2014 at 12:56 AM, Russell Nelson <russnelson(a)gmail.com> wrote: > Google by users and they'll be subject to Google's privacy policy. Simply a > non-starter. Which is why it has been dropped. Also, please note that the topic of discussion is whether to move Nearby out of MobileFrontend. I understand now that WMF will/might need its own tile server before any sufficient progress can be made on this. —prtksxna _______________________________________________ Mobile-l mailing list Mobile-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l

1 0

New Android Alpha release!
by Dmitry Brant 07 May '14

07 May '14

We have an updated alpha version of the Android app available on the Play Store. If you'd like to opt in to get automatic updates of the alpha version, please follow these instructions: http://lists.wikimedia.org/pipermail/mobile-l/2014-March/006642.html What's new in this release: - Renamed "Saved Pages" to "Bookmarks", and no longer storing page content locally. - The table-of-contents for each page now slides out from the right-hand side, just like the main menu slides from the left. - Horizontal scrolling for extra-wide page content now works properly. - Plenty of other fixes for bugs and crashes. -- Dmitry Brant http://dmitrybrant.com

2 1

client-side storage plug-ins (opinions needed)
by Ryan Kaldari 06 May '14

06 May '14

Recently, I decided to clean-up some of the code in MobileFrontend related to localStorage. The other mobile devs suggested that I implement a generalized solution that could be upstreamed to core. I looked at some 3rd party jQuery plug-ins and decided to implement a solution based on jQuery Store. I stripped out all the extraneous crap and added support for cookies (since localStorage quotas are often rather small for mobile devices) and caching. The end result can be seen at: https://gerrit.wikimedia.org/r/#/c/131239/ After I checked this in, I was informed that there is already a client-side storage plug-in in core: jStorage, as well as another one being used by Flow, Storer. Both of these seem a bit like overkill to me and I would prefer to implement something simple and light-weight for mobile. Also jStorage doesn't support fall-back to cookies. What are people's opinions on moving forward on this? Should mobile have it's own lightweight plug-in, should we modify jStorage in core so that it meets our requirements, or should we adopt Storer and push for it to replace jStorage in core? Ryan Kaldari

3 3

mobile-l@lists.wikimedia.org收；战略性人力资源管理
by 宫先生 06 May '14

06 May '14

1 0

Re: [WikimediaMobile] Help me get the tests passing again
by Jon Robson 06 May '14

06 May '14

When I view the Nearby test confusingly it tells me it passed... hence the confusion :) On Tue, May 6, 2014 at 9:50 AM, Chris McMahon <cmcmahon(a)wikimedia.org> wrote: > > > > On Tue, May 6, 2014 at 9:12 AM, Jon Robson <jrobson(a)wikimedia.org> wrote: >> >> https://gerrit.wikimedia.org/r/131714 fixes the toggling tests >> https://gerrit.wikimedia.org/r/131715 fixes the uploads. >> KeepGoing... not sure what's going on there but continuing to investigate. >> Nearby same.. ran tests locally and they seem to work fine. > > > For the Nearby test, click through to the SauceLabs jobs from > https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs… > and watch the screencast. > > Looks like a browser glitch: the test sets Beta mode and clicks Save, and > then Chrome freaks out and says "No data received" > > I am looking forward to running these from the WMF Jenkins. > > -C > >

1 0

Re: [WikimediaMobile] Help me get the tests passing again
by Jon Robson 06 May '14

06 May '14

I've now identiifed the problem with KeepGoing. https://gerrit.wikimedia.org/r/131722 On Tue, May 6, 2014 at 9:12 AM, Jon Robson <jrobson(a)wikimedia.org> wrote: > https://gerrit.wikimedia.org/r/131714 fixes the toggling tests > https://gerrit.wikimedia.org/r/131715 fixes the uploads. > KeepGoing... not sure what's going on there but continuing to investigate. > Nearby same.. ran tests locally and they seem to work fine. > > On Mon, May 5, 2014 at 9:43 PM, <jenkins-no-reply(a)cloudbees.com> wrote: > >> * FAILURE: MobileFrontend-en.m.wikipedia.beta.wmflabs.org-linux-chrome >> Build #427 >> <https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs…> >> (Tue, 06 May 2014 04:08:17 +0000)* >> *Test Result*<https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs…> >> 5 failed, 0 skipped >> Failed Tests *Test Name**Duration**Age* Encourage new users to Keep >> Going.I see a KeepGoing message after completing my VisualEditor edit<https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs…> 1 >> min 11 sec11<https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs…> Nearby >> pages.Nearby button visible<https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs…> 19 >> sec1<https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs…> Special:Uploads >> uploads.Upload image file<https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs…> 23 >> sec1<https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs…> Toggling >> sections.Closing a section<https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs…> 12 >> sec1<https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs…> Toggling >> sections.Opening a section<https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs…> 1.9 >> sec1<https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs…> All >> Tests *Package**Duration**Fail**Skip**Total* (root)<https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs…>26 >> min5080 >> > >

1 0

Fwd: [Wikimedia-l] Mobile Operator IP Drift Tracking and Remediation
by Adam Baso 02 May '14

02 May '14

FYI, added sampling ---------- Forwarded message ---------- From: Adam Baso <abaso(a)wikimedia.org> Date: Fri, May 2, 2014 at 1:16 PM Subject: Re: [Wikimedia-l] Mobile Operator IP Drift Tracking and Remediation To: Wikimedia Mailing List <wikimedia-l(a)lists.wikimedia.org> Federico asked if sampling might make sense here. I think it will work, so I've updated the patchset. >From a patchset comment I provided: "It's possible we may have situations where operators have not lots of users on them accessing Wiki(m|p)edia properties, so we do run some risk of actually missing IPs, even if exit IPs are concentrators of typically large sets of users. That said, let's try a 2% sample ratio; and if we find out it's insufficient, then we'll sample more, if it's oversampling, then we can adjust the other way, too. New patchset arriving shortly." (I've since submitted the updated code for review.) -Adam On Thu, May 1, 2014 at 7:52 PM, Adam Baso <abaso(a)wikimedia.org> wrote: > After examining this, it looks like EventLogging is more suited to the > logging task than debug logging and the trappings of needing to alter debug > logging in the core MediaWiki software. > > EventLogging logs at the resolution of a second (instead of a day), but > has inbuilt support for record removal after 90 days. > > Please do let us know in case of further questions. Here's the logging > schema for those with an interest: > > https://meta.wikimedia.org/wiki/Schema:MobileOperatorCode > > Here's the relevant server code: > > https://gerrit.wikimedia.org/r/#/c/130991/ > > -Adam > > > > > On Wed, Apr 16, 2014 at 2:20 PM, Adam Baso <abaso(a)wikimedia.org> wrote: > >> Great idea! >> >> Anyone on the list know if there's a way to make the debug log facilities >> do the YYYYMMDD timestamp instead of the longer one? >> >> If not, I suppose we could work to update the core MediaWiki code. [1] >> >> -Adam >> >> 1. For those with PHP skills or equivalent, I'm referring to >> https://git.wikimedia.org/blob/mediawiki%2Fcore.git/a26687e81532def3faba646…. >> Scroll to the bottom of the function definition to see the datetimestamp >> approach. >> >> >> On Wed, Apr 16, 2014 at 12:47 PM, Andrew Gray <andrew.gray(a)dunelm.org.uk>wrote: >> >>> Hi Adam, >>> >>> One thought: you don't really need the date/time data at any detailed >>> resolution, do you? If what you're wanting it for is to track major >>> changes ("last month it all switched to this IP") and to purge old >>> data ("delete anything older than 10 March"), you could simply log day >>> rather than datetime. >>> >>> enwiki / 127.0.0.1 / 123.45 / 2014-04-16:1245.45 >>> >>> enwiki / 127.0.0.1 / 123.45 / 2014-04-16 >>> >>> - the latter gives you the data you need while making it a lot harder >>> to do any kind of close user-identification. >>> >>> Andrew. >>> On 16 Apr 2014 19:17, "Adam Baso" <abaso(a)wikimedia.org> wrote: >>> >>> > Inline. >>> > >>> > Thanks for starting this thread. >>> > > >>> > > Sorry if I've overlooked this, but who/what will have access to this >>> > data? >>> > > Only members of the mobile team? Local project CheckUsers? Wikimedia >>> > > Foundation-approved researchers? Wikimedia shell users? AbuseFilter >>> > > filters? >>> > > >>> > >>> > It's a good question. The thought is to put it in the customary >>> wfDebugLog >>> > location (with, for example, filename "mccmnc.log") on fluorine. >>> > >>> > It just occurred to me that the wiki name (e.g., "enwiki"), but not the >>> > full URL, gets logged additionally as part of the wfDebugLog call; to >>> make >>> > the implicit explicit, wfDebugLog adds a datetime stamp as well, and >>> that's >>> > useful for purging old records. I'll forward this email to mobile-l and >>> > wikitech-l to underscore this. >>> > >>> > >>> > > And this may be a silly question, but is there a reasonable means of >>> > > approximating how identifying these two data points alone are? That >>> is, >>> > > Using a mobile country code and exit IP address, is it possible to >>> > > identify a particular editor or reader? Or perhaps rephrased, is this >>> > data >>> > > considered anonymized? >>> > > >>> > >>> > Not a silly question. My approximation is these tuples (datetime, now >>> that >>> > it hit me - XYwiki, exit IP, and MCC-MNC) alone, although not perfectly >>> > anonymized, are low identifying (that is, indirect inferences on the >>> data >>> > in isolation are unlikely, but technically possible, through >>> examination of >>> > short tail outliers in a cluster analysis where such readers/editors >>> exist >>> > in the short tail outliers sets), in contrast to regular web access >>> logs >>> > (where direct inferences are easy). >>> > >>> > Thanks. I'll forward this along now. >>> > >>> > -Adam >>> > _______________________________________________ >>> > Wikimedia-l mailing list >>> > 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 >>> Wikimedia-l(a)lists.wikimedia.org >>> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, >>> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe> >>> >> >> >

1 0

Fwd: [Wikimedia-l] Mobile Operator IP Drift Tracking and Remediation
by Adam Baso 02 May '14

02 May '14

Update. ---------- Forwarded message ---------- From: Adam Baso <abaso(a)wikimedia.org> Date: Thu, May 1, 2014 at 7:52 PM Subject: Re: [Wikimedia-l] Mobile Operator IP Drift Tracking and Remediation To: Wikimedia Mailing List <wikimedia-l(a)lists.wikimedia.org> After examining this, it looks like EventLogging is more suited to the logging task than debug logging and the trappings of needing to alter debug logging in the core MediaWiki software. EventLogging logs at the resolution of a second (instead of a day), but has inbuilt support for record removal after 90 days. Please do let us know in case of further questions. Here's the logging schema for those with an interest: https://meta.wikimedia.org/wiki/Schema:MobileOperatorCode Here's the relevant server code: https://gerrit.wikimedia.org/r/#/c/130991/ -Adam On Wed, Apr 16, 2014 at 2:20 PM, Adam Baso <abaso(a)wikimedia.org> wrote: > Great idea! > > Anyone on the list know if there's a way to make the debug log facilities > do the YYYYMMDD timestamp instead of the longer one? > > If not, I suppose we could work to update the core MediaWiki code. [1] > > -Adam > > 1. For those with PHP skills or equivalent, I'm referring to > https://git.wikimedia.org/blob/mediawiki%2Fcore.git/a26687e81532def3faba646…. > Scroll to the bottom of the function definition to see the datetimestamp > approach. > > > On Wed, Apr 16, 2014 at 12:47 PM, Andrew Gray <andrew.gray(a)dunelm.org.uk>wrote: > >> Hi Adam, >> >> One thought: you don't really need the date/time data at any detailed >> resolution, do you? If what you're wanting it for is to track major >> changes ("last month it all switched to this IP") and to purge old >> data ("delete anything older than 10 March"), you could simply log day >> rather than datetime. >> >> enwiki / 127.0.0.1 / 123.45 / 2014-04-16:1245.45 >> >> enwiki / 127.0.0.1 / 123.45 / 2014-04-16 >> >> - the latter gives you the data you need while making it a lot harder >> to do any kind of close user-identification. >> >> Andrew. >> On 16 Apr 2014 19:17, "Adam Baso" <abaso(a)wikimedia.org> wrote: >> >> > Inline. >> > >> > Thanks for starting this thread. >> > > >> > > Sorry if I've overlooked this, but who/what will have access to this >> > data? >> > > Only members of the mobile team? Local project CheckUsers? Wikimedia >> > > Foundation-approved researchers? Wikimedia shell users? AbuseFilter >> > > filters? >> > > >> > >> > It's a good question. The thought is to put it in the customary >> wfDebugLog >> > location (with, for example, filename "mccmnc.log") on fluorine. >> > >> > It just occurred to me that the wiki name (e.g., "enwiki"), but not the >> > full URL, gets logged additionally as part of the wfDebugLog call; to >> make >> > the implicit explicit, wfDebugLog adds a datetime stamp as well, and >> that's >> > useful for purging old records. I'll forward this email to mobile-l and >> > wikitech-l to underscore this. >> > >> > >> > > And this may be a silly question, but is there a reasonable means of >> > > approximating how identifying these two data points alone are? That >> is, >> > > Using a mobile country code and exit IP address, is it possible to >> > > identify a particular editor or reader? Or perhaps rephrased, is this >> > data >> > > considered anonymized? >> > > >> > >> > Not a silly question. My approximation is these tuples (datetime, now >> that >> > it hit me - XYwiki, exit IP, and MCC-MNC) alone, although not perfectly >> > anonymized, are low identifying (that is, indirect inferences on the >> data >> > in isolation are unlikely, but technically possible, through >> examination of >> > short tail outliers in a cluster analysis where such readers/editors >> exist >> > in the short tail outliers sets), in contrast to regular web access logs >> > (where direct inferences are easy). >> > >> > Thanks. I'll forward this along now. >> > >> > -Adam >> > _______________________________________________ >> > Wikimedia-l mailing list >> > 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 >> Wikimedia-l(a)lists.wikimedia.org >> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, >> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe> >> > >

1 0

Mobile App Retrospective notes are up on the wiki
by Tomasz Finc 01 May '14

01 May '14

The Mobile App team had their monthly retrospective today. Notes, further discussion, and action items are below. https://www.mediawiki.org/wiki/Wikimedia_Apps/imported/Retrospective-May_1_… = Further discussion items = * We should probably whittle Saved Pages down a bit. Me and dbrant have started on patches. +++ [Yuvi] * Communication / Interaction with Design (+)() [Maryana] * Release timeline. Beginning of sprint we mentioned android to beta at end of sprint and then no mention after ++ [Maryana] * Not enough comments and discussion on the design trello board+++ [team] Thanks team and all involved. --tomasz

1 0

Is there a way to mark tests as reviewed in Jenkins?
by Jon Robson 01 May '14

01 May '14

When I visit the dashboard at https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs… and click on this https://wmf.ci.cloudbees.com/job/MobileFrontend-en.m.wikipedia.beta.wmflabs… I can see that there was one test failure. When I review the test I notice this was due to an issue with betalabs and shouldn't have failed as the test wasn't valid. Is there anyway we could update the UI so we could mark these tests yellow or some other colour to show they are a false positive. It would be great to be able to manually review these tests and save them being reviewed more than once... Thoughts? Jon

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

Mobile-l May 2014