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.
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
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
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
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
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…
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/HwGK5RvNOFIhttp://i.imgur.com/DWrI2JY.gif
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
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
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-extendhttp://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).
