Mobile-l April 2015

mobile-l@lists.wikimedia.org

47 participants
42 discussions

Mobile Newsletter?
by Moushira Elamrawy 21 Apr '15

21 Apr '15

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

3 3

Commons Reloaded
by Maarten Dammers 17 Apr '15

17 Apr '15

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

17 33

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

15 Apr '15

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

6 7

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

15 Apr '15

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

3 3

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

15 Apr '15

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

1 0

Fixed Android alpha build
by Bernd Sitzmann 14 Apr '15

14 Apr '15

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

1 0

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

14 Apr '15

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

6 7

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

14 Apr '15

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

1 0

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

11 Apr '15

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

1 0

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

10 Apr '15

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

5 9

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

Mobile-l April 2015