Mobile-l January 2015

mobile-l@lists.wikimedia.org

30 participants
21 discussions

Re: [WikimediaMobile] tmi (too many images)
by Jon Robson 30 Jan '15

30 Jan '15

Moving to mobile-l. The main page changes a lot so it is not the best example. Today for example our image weight is 15.36 kB I'm a little confused what strategy=mobile does differently to strategy=desktop - any idea what that is doing differently? Note there is also a verbose mode: > tmi en.m.wikipedia.org/wiki/Main_page --verbose With recommendations to optimise the following images (there is one more but that is outside our control - it is a thumbnail of an image): http://en.m.wikipedia.org/images/mobile/wikipedia-wordmark-en.png Size: 1.8KiB Can be improved by 61% (good to know - I'm not sure where this file lives... how can we get this optimised?) The Barack Obama article is more damning (~1.97 MB with strategy=mobile whatever that means and 590.06 kB with strategy desktop). Sam Smith and I have been talking about only rendering the lead section in a future version of mobile and delaying loading of images / sections until they are needed. We previously explored this but it didn't get enough support and I think it is worth revisiting now the MobileFrontend code is in a stronger place.

3 4

Android Wikipedia Beta app update
by Bernd Sitzmann 28 Jan '15

28 Jan '15

Dear Android Wikipedia Beta app users, We just published a new beta release, which should be available through the store in a couple of hours. Here are the changes: * Image gallery: when viewing images in full screen you can now also swipe left/right to see other images on the same page, in addition to the already available pinch to zoom and pan * Minor lead image adjustments for parallax scrolling * Hardware search button (usually on older devices) opens search * No longer hide hatnotes in non-lead sections * Don't duplicate history entries; instead, move them to top Please report any issues you find. Thank you, Bernd

3 3

Re: [WikimediaMobile] trouble running browsers tests
by Jon Robson 23 Jan '15

23 Jan '15

Forwarding to mobile-l and QA Firstly running browser tests for those that do not know: Go to MobileFrontend directory and run `make cucumber` or cd into tests/browser and run bundle exec cucumber features/*.feature I'm assuming you are running `make cucumber` as interestingly it seems that the very first test runs in the desktop site not mobile. (Fix @ https://gerrit.wikimedia.org/r/186320 - please someone merge) It's essential the step "I am using the mobile site" is present in the tests, as otherwise the test will run on the desktop site. Does this solve your issue Ryan? On Wed, Jan 21, 2015 at 12:49 PM, Ryan Kaldari <rkaldari(a)wikimedia.org> wrote: > I recently tried running the browser tests locally which I hadn't done in a > while. Unlike previously, all of the tests ran in desktop mode instead of > mobile mode. I tried it both on vagrant and non-vagrant installs, but no > luck. What's the trick to forcing the browser tests to run in mobile mode? > > Kaldari

3 2

[Apps] Reader experience... it's a thing.
by Dan Garry 21 Jan '15

21 Jan '15

I'm putting together data for our planning sessions and I'm assembling a few representative screenshots. I looked at a few articles, comparing the builds that we had in production on Android at the start and the end of Q2. It's like night and day. At the start of Q2: http://i.imgur.com/HDQ9HrR.png At the end of Q2: http://i.imgur.com/3X0U9Uw.png We served our users well. Be proud. I know I am. Dan -- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation

1 0

Re: [WikimediaMobile] Xcode plugin for comments
by Tomasz Finc 21 Jan '15

21 Jan '15

Nothing private here. CC'ing mobile-l@ --tomasz On Tue, Jan 20, 2015 at 4:06 PM, Brian Gerstle <bgerstle(a)wikimedia.org> wrote: > And it works with Swift, very nice! > > On Tue, Jan 20, 2015 at 4:05 PM, Corey Floyd <cfloyd(a)wikimedia.org> wrote: >> >> >> Great plugin that makes comments super easy: >> https://github.com/onevcat/VVDocumenter-Xcode >> >> Just type "///" and it auto-populates your comment block. >> >> You can install manually or using Alcatraz - a plugin manager for Xcode: >> http://alcatraz.io/ >> >> >> >> >> > > > > -- > EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle > IRC: bgerstle

1 0

POTY mobile application
by Rainer Rillke 20 Jan '15

20 Jan '15

Yallah! The ninth POTY is running this year[0] and I dare to say it's the vote with most participation across the Wikimedia Empire to my knowledge. We usually have over 1000 eligible voters (had 3390 in 2013) and a vote volume of over 10000 (had 130000 in 2013) [1]. And I, together with 4(+-1) other committee members and a great and helpful community, am organizing every year's contest since a while. Mobile usage is increasing and the mobile/web interface is getting more usable. So we are wondering what'd be the best way to port POTY App to mobile. Surely there have to be adoptions to the interface but this is not what I am wondering about. I am more interested in - People interested in volunteering porting the application to mobile - Helpful advice how to design such a mobile product -- How to load scripts? Is [[MediaWiki:Mobile.js]] the only way to achieve that? -- Which libraries are additionally available; Which from Desktop are missing? -- A link to a good introduction into mobile development in general and with MediaWiki. Rainer Rillke Technical Director - Picture of the Year Election's Committee[2] [0] https://commons.wikimedia.org/wiki/Commons:Picture_of_the_Year/2014 [1] https://docs.google.com/presentation/d/1X4VG9AWxmmhLfyRDFHUlEQWmoN09-GtEdxC… [2] https://commons.wikimedia.org/wiki/Commons:Picture_of_the_Year/2014/Committ…

1 0

Long-form editing on mobile
by Monte Hurd 19 Jan '15

19 Jan '15

I think we're all aware of the challenges of editing on mobile, especially when it comes to long-form editing. Does the device in the following video make anyone else feel hopeful about the future of long-form edits on mobile? http://youtu.be/HwGK5RvNOFI http://i.imgur.com/DWrI2JY.gif

4 4

[Android] App update
by Dmitry Brant 15 Jan '15

15 Jan '15

Our latest update to the official Wikipedia Android app is now available on the Google Play Store! [1] Here's a high-level overview of the features introduced in this release: * Lead images -- When navigating to an article, the app now displays the most relevant image from the article at the very top, with the image expanded to fit the width of your screen, and the title of the article overlaid onto it. * Image gallery -- Tap on any image in an article (including the lead image) to see a full-screen gallery where the image may be panned and zoomed. You may also "swipe" left and right to browse through other images that are part of the article. There are also options, accessible from the toolbar on the top right, for sharing the image to your favorite social media apps, saving it directly to your device, showing miscellaneous information (Exif) about the image, and navigating to its File: page on Wikipedia. * Descriptions from Wikidata -- The app is now integrated with Wikidata [2] to provide quick descriptions next to search results, as well as in Nearby results, in disambiguation links, and in further reading suggestions. * Search enhancements -- We have improved the search experience (accessible from the top toolbar) to intelligently incorporate search results from title-only searches, as well as full-text searches, so that typing a search term will give you the most relevant result. * Disambiguation and "page issues" links have been improved and restyled. * Suggestions for further reading are provided at the bottom of articles. * Infoboxes and other tables contained in articles are now collapsed by default. * The toolbar at the top has been restyled to follow the new Material Design guidelines introduced in Android 5.0. * When editing, templates are shown in a different color to help differentiate between the template and regular text. Enjoy! -- Dmitry Brant Mobile Apps Team (Android) Wikimedia Foundation https://www.mediawiki.org/wiki/Wikimedia_mobile_engineering [1] https://play.google.com/store/apps/details?id=org.wikipedia [2] http://wikidata.org

2 1

Testing extensions together
by Antoine Musso 12 Jan '15

12 Jan '15

Hello Mobile! Fairly recently, a code cleanup in Mantle caused a back compatibility issue with several other extensions such as MobileFrontend and ZeroPortal. It could have been caught if, when the Mantle patch has been proposed, we had Jenkins to run the tests of the other extensions. Over the summer I wrote code that supports testing extensions together and I wrote an RFC which got approved [RFC] I am now looking for extensions to tests together and the mobile related ones seems to be good candidate. If you agree, I will craft a Jenkins job that clones: - Mediawiki core + Vendor - JsonConfig - Mantle - MobileApp - MobileFrontend - WikiGrok - ZeroBanner - ZeroPortal And run the MediaWiki PHPUnit test suite. The new job, will be triggered for changes made on any of those repositories and be non voting while it is being refined. Once we are happy about it, I would remove the '-testextension' jobs and make it voting. Next, we can reuse the same logic for -qunit and -qunit-mobile jobs and ends up with well integrated set of repositories. The evil plan for next year, is to extend that to all extensions deployed on the Wikimedia cluster. Crazy? [RFC] tis a long read https://www.mediawiki.org/wiki/RFC/Extensions_continuous_integration -- Antoine "hashar" Musso

3 9

Declarative DOM event delegation in JS views
by Joaquin Oltra Hernandez 08 Jan '15

08 Jan '15

I'm happy to announce that we've landed on Mantle and MobileFrontend a new way to specify DOM events on a javascript view that I think will make our views better in several ways. TLDR: * Backbone style declarative delegated DOM events handling is in Mantle's View class. Use it when possible. TOC: * Why. Current approach to binding events * A different proven approach, delegated declarative DOM events map * Examples of this in MobileFrontend * Good practices and conventions * Gotchas * Next steps Why. Current approach to binding events --------------------------------------- Currently on JS views, when we want to bind some events to the view, we bind them on the `postRender` method, like so: var CounterView = View.extend({ // ... postRender: function() { // View display logic this.$('.increment').click(function(ev) { // ... }) this.$('.reset').click(function(ev) { // ... }) }, // ... }) With the current approach, a few bad side effects follow: * Everytime the view renders, we bind events (multiple of them), this is inefficient, there are better ways. * The postRender method on views grows a lot in size, event handling declarations and method code is mixed with display logic. * The complexity of the view (arguably) increases, and with it the ability to read and modify the source confidently. A different proven approach, delegated declarative dom events map ----------------------------------------------------------------- Inspired and brought from Backbone.js, we have ported their dom events map, which brings a way of specifying event and selector, and a handler that will be bound to the view, declaratively on the view itself, the same way we specify defaults, for example. http://backbonejs.org/#View-extend http://backbonejs.org/#View-delegateEvents The previous example, with this approach with our views would be: var CounterView = View.extend({ // ... events: { 'click .increment': 'increment', 'click .reset': 'reset', }, postRender: function() { // View display logic }, increment: function() { this.counter++; }, reset: function() { this.counter=0; }, // ... }) On View, we can now specify a `events` entry, which is a map of `event selector`: handler Where event is any valid jQuery event, selector is any valid jQuery selector, and handler is either a function, or a string (name of a method on the view). With this approach: * Events are bound with delegate, effectively attaching one DOM listener on the view's root DOM element. (Read http://api.jquery.com/on/#direct-and-delegated-events) * To see which DOM events the view binds and reacts to, just need to find the events map of the view. * Event handling code (usually pieces of logic of the view) gets a name, and it's encapsulated on its own method giving us: * Reuse of such logic/functionality * Easier and better testability * Cleaner postRender methods Internally, this is just using jQuery to delegate the events and the selectors to specified handlers bound to the view, no black magic. Examples of this in MobileFrontend ---------------------------------- https://gerrit.wikimedia.org/r/#/c/180835/ https://gerrit.wikimedia.org/r/#/c/180836/ https://gerrit.wikimedia.org/r/#/c/180837/ Notice that the code is much less nested and comes back to View level. In some cases the postRender method becomes unnecessary, and is deleted, and the code that was on it, has now a name and is properly encapsulated on the view. Good practices and conventions ------------------------------ When creating event handlers, if they are doing DOM stuff, like preventDefault, or extracting data from the DOM node, manipulating the DOM, etc, you should name the handler `onEvent`, for example `onThanksClick` or `onHeaderToggle`. If possible, extract functionality that makes sense independently into methods with a good name and call them from the handlers as needed. When creating methods on a view, like the `increment` example above, that happen to be called when an event happens but make sense independently, I would argue that a method name `increment` makes more sense than a handler name `onIncrementClick`, but that is open to common sense and taste I guess. If I had to also extract what to increment from a DOM element, and then increment, then I would do both, for example: // ... events: { 'click .increment': 'onIncrementClick' }, onIncrementClick: function(ev) { var amount = parseFloat(this.$('.amount').val()); this.increment(amount); }, increment: function(amount) { this.counter += amount || 1; }, // ... Gotchas ------- Currently, a common practice is inside a event handler to access the DOM element that initiated the event doing `$(this)`. With the events map the handlers/methods are at view level and are consistently bound to the view's this, so how do we access the DOM element of the event? Handler methods get an jQuery.Event as a parameter, so: onIncrementClick: function(ev) { var $incButton = $(ev.target); // ... http://api.jquery.com/category/events/event-object/ Next steps ---------- If there is any doubts or concerns, please ask them. If you find going along the code you spot a View that could benefit of this approach, open a Phabricator task (prefixed with "Hygiene" and in the MobileWeb team) and take on it ifyou want. I think this gives us a good opportunity to get more view tests, and make the code cleaner, more understandable and approachable for both us and possible contributors (Backbone style views are known by everybody at this point).

3 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

Mobile-l January 2015