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 )
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
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
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
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]])
> 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)
"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
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 :-))