Re: [Wikimedia-l] How can we fix the two-stage page loading problem?

[Dennis During]

Can we get back on topic please?  I isn't  there another thread for beating
the fundraising-disclosure-oversight dead horse?
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] How can we fix the two-stage page loading problem?

[David Emrany]

Dear Joseph

Thanks for that link.

*NB*: I hope that the list moderators shall not censor / block / unduly
delay this important internal conversation we are having concerning WMF
self-financing model.

Since this concerns the WMF fund-raising drives of Nov-Dec 2016, I'm
linking to the following messages

1. *[Wikimedia-l] [Wikimedia Announcements] Wikimedia Foundation Form 990
for FY 2014-2015 now on-wiki*


*"WMF's sheer wastage of donated money (incl. lunch
money from Scottish schoolkids) on unnecessary litigation, I cite that
the single most prominent case they defended in the period was
apparently a domain name dispute (said to billed at US$ 317,490) in
which the opposite party (a Wikipedian of long standing) who had only
booked the domain name to prevent it from being snaffled by "cyber
squatters"  had immediately offered to donate it WMF free of cost
before the case began. Had WMF accepted that voluntary and good faith
donation offer, they would have also got back 75% of the filing fees
(a not insubstantial amount).

Dave"*


2. *Reply by Greg Varnum (WMF) on this mailing list*










*"As for the question about why the Wikimedia Foundationspent $317,490
fighting "cybersquatters" that offeredto donate the domain in dispute:
We’re not sure where this question comes from, as we haven’t dealt
with a case that fits this description. We do not fight cybersquatters
who offer to donate their domains (especially if they are community
members),and, to date, we have not spent anything approachingthat much
money on this type of case."*


3.   *Your donation keeps Wikipedia and free knowledge thriving*


"Legal defense to preserve your right to access, share, and remix
knowledge, including court battles won over Wikimedia content in Brazil
, Germany
,
France , and
India."

including unreplied comments on why the India court battles were not linked
unlike the others
So to sum up:

1. The WMF form 990 says US law firm "JonesDay" received US$ 1,742,916 for
legal services in 2014-15

2. WMF is unprepared to specifically inform the community how much of that
was spent on fighting a specific "cyber-squatter" from India (my own
sources at the time said US$ 300,000 was paid by WMF to JonesDay for this
case, mainly billable hours for JD partner Carrie Kiedrowski).

3. WMF is unprepared to specifically inform the community whether or not
this cyber squatter (who claims to be a community member since 2003) had
straightaway offered to donate the domain name free of cost to the WMF and
close the case, however, WMF rejected the offer and instead ran up huge
legal bills which were financed by donations, and probably continues to do
so since that case is still ongoing in India's legal system .

4. I distinctly recall that when I was in India in mid-November 2016,
attending the Opendaylight Linux forum in Bengaluru and incidentally
discussing there the progress of this legal case with the other party who
was an attendee, I was bombarded with WMF donation banner-ads, as a
logged-in user, which carried through till mid-December 2016 when I was at
Sri Lanka and Kathmandu but which curiously stopped when I reached
Austraila.

5. So, as a community member and contributor, I would like to know how
every dollar raised by WMF is collected, and also spent thereafter.

Warmly

David


On Fri, Sep 8, 2017 at 3:52 PM, Joseph Seddon 
wrote:

> Hi David,
>
> I would refer to my answer I gave on the forked thread relating to this
> topic.
>
> https://lists.wikimedia.org/pipermail/wikimedia-l/2017-
> September/088570.html
>
> Regards
> Seddon
>
> On Wed, Sep 6, 2017 at 3:46 PM, David Emrany 
> wrote:
>
> > Sure Lodewijk,
> >
> > Banners from December 2016:
> > https://commons.wikimedia.org/wiki/File:Inline_donor_bannerbass.png
> > https://upload.wikimedia.org/wikipedia/commons/1/1d/Inline_
> > donor_bannerbass.png
> >
> > Comments from Seddon
> > https://lists.wikimedia.org/pipermail/wikimedia-l/2016-
> > December/085612.html
> >
> > Perhaps these banners were muted for logged-in users in USA, but I was
> > in S-E Asia last December and it was a very unpleasant experience for
> > me, especially while on mobile and logged in, to get a begging
> > banner/pop-up about after every 4 pages I loaded.
> >
> > David
> >
> > On 9/6/17, Lodewijk  wrote:
> > > Hi David,
> > >
> > > Would you mind elaborating on the first point? I vaguely recall test
> > > banners being shown to logged in users, but don't recall seeing one
> > myself
> > > while logged in for a while.
> 

Re: [Wikimedia-l] How can we fix the two-stage page loading problem?

[Lodewijk]

hi david,

as with your accusations regarding the spending, my question would be whether
you have anything to substantiate it. Seddon was clear: it did not happen,
unless perhaps a human error in a minimal number of campaigns. If you have
that then please bring that up in a *separate* thead.

you're going more and more off topic. I suggest that we return to the question
at hand: the two stage loading problem.

lodewijk

On Mon, Sep 11, 2017 at 8:41 AM, David Emrany 
wrote:

> Dear Joseph
>
> Thanks for that link.
>
> *NB*: I hope that the list moderators shall not censor / block / unduly
> delay this important internal conversation we are having concerning WMF
> self-financing model.
>
> Since this concerns the WMF fund-raising drives of Nov-Dec 2016, I'm
> linking to the following messages
>
> 1. *[Wikimedia-l] [Wikimedia Announcements] Wikimedia Foundation Form 990
> for FY 2014-2015 now on-wiki*
> 
>
> *"WMF's sheer wastage of donated money (incl. lunch
> money from Scottish schoolkids) on unnecessary litigation, I cite that
> the single most prominent case they defended in the period was
> apparently a domain name dispute (said to billed at US$ 317,490) in
> which the opposite party (a Wikipedian of long standing) who had only
> booked the domain name to prevent it from being snaffled by "cyber
> squatters"  had immediately offered to donate it WMF free of cost
> before the case began. Had WMF accepted that voluntary and good faith
> donation offer, they would have also got back 75% of the filing fees
> (a not insubstantial amount).
>
> Dave"*
>
>
> 2. *Reply by Greg Varnum (WMF) on this mailing list*
> 
>
>
>
>
>
>
>
>
>
> *"As for the question about why the Wikimedia Foundationspent $317,490 
> fighting "cybersquatters" that offeredto donate the domain in dispute: We’re 
> not sure where this question comes from, as we haven’t dealt with a case that 
> fits this description. We do not fight cybersquatters who offer to donate 
> their domains (especially if they are community members),and, to date, we 
> have not spent anything approachingthat much money on this type of case."*
>
>
> 3.   *Your donation keeps Wikipedia and free knowledge thriving*
> 
>
> "Legal defense to preserve your right to access, share, and remix
> knowledge, including court battles won over Wikimedia content in Brazil
> , Germany
> ,
> France , and
> India."
>
> including unreplied comments on why the India court battles were not
> linked unlike the others
> So to sum up:
>
> 1. The WMF form 990 says US law firm "JonesDay" received US$ 1,742,916 for
> legal services in 2014-15
>
> 2. WMF is unprepared to specifically inform the community how much of that
> was spent on fighting a specific "cyber-squatter" from India (my own
> sources at the time said US$ 300,000 was paid by WMF to JonesDay for this
> case, mainly billable hours for JD partner Carrie Kiedrowski).
>
> 3. WMF is unprepared to specifically inform the community whether or not
> this cyber squatter (who claims to be a community member since 2003) had
> straightaway offered to donate the domain name free of cost to the WMF and
> close the case, however, WMF rejected the offer and instead ran up huge
> legal bills which were financed by donations, and probably continues to do
> so since that case is still ongoing in India's legal system .
>
> 4. I distinctly recall that when I was in India in mid-November 2016,
> attending the Opendaylight Linux forum in Bengaluru and incidentally
> discussing there the progress of this legal case with the other party who
> was an attendee, I was bombarded with WMF donation banner-ads, as a
> logged-in user, which carried through till mid-December 2016 when I was at
> Sri Lanka and Kathmandu but which curiously stopped when I reached
> Austraila.
>
> 5. So, as a community member and contributor, I would like to know how
> every dollar raised by WMF is collected, and also spent thereafter.
>
> Warmly
>
> David
>
>
> On Fri, Sep 8, 2017 at 3:52 PM, Joseph Seddon 
> wrote:
>
>> Hi David,
>>
>> I would refer to my answer I gave on the forked thread relating to this
>> topic.
>>
>> https://lists.wikimedia.org/pipermail/wikimedia-l/2017-Septe
>> mber/088570.html
>>
>> Regards
>> Seddon
>>
>> On Wed, Sep 6, 2017 at 3:46 PM, David Emrany 
>> wrote:
>>
>> > Sure Lodewijk,
>> >
>> > Banners from December 2016:
>> > https://commons.wikimedia.org/wiki/File:Inline_donor_bannerbass.png
>> > https://upload.wikimedia.org/wikipedia/commons/1/1d/Inline_
>> > 

Re: [Wikimedia-l] How can we fix the two-stage page loading problem?

[Joseph Seddon]

Hi David,

I would refer to my answer I gave on the forked thread relating to this
topic.

https://lists.wikimedia.org/pipermail/wikimedia-l/2017-September/088570.html

Regards
Seddon

On Wed, Sep 6, 2017 at 3:46 PM, David Emrany  wrote:

> Sure Lodewijk,
>
> Banners from December 2016:
> https://commons.wikimedia.org/wiki/File:Inline_donor_bannerbass.png
> https://upload.wikimedia.org/wikipedia/commons/1/1d/Inline_
> donor_bannerbass.png
>
> Comments from Seddon
> https://lists.wikimedia.org/pipermail/wikimedia-l/2016-
> December/085612.html
>
> Perhaps these banners were muted for logged-in users in USA, but I was
> in S-E Asia last December and it was a very unpleasant experience for
> me, especially while on mobile and logged in, to get a begging
> banner/pop-up about after every 4 pages I loaded.
>
> David
>
> On 9/6/17, Lodewijk  wrote:
> > Hi David,
> >
> > Would you mind elaborating on the first point? I vaguely recall test
> > banners being shown to logged in users, but don't recall seeing one
> myself
> > while logged in for a while.
> >
> > Best,
> > Lodewijk
> >
> > On Tue, Sep 5, 2017 at 2:16 PM, David Emrany 
> wrote:
> >
> >> a) This is incorrect
> >> b) how many years would "for several years" encompass?
> >>
> >> David
> >>
> >> On 9/5/17, Joseph Seddon  wrote:
> >> > WMF hasn't shown fundraising banners to logged in users for several
> >> years.
> >> >
> >> > Regards
> >> > Seddon
> >>
>
> ___
> Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/
> wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/
> wiki/Wikimedia-l
> New messages to: Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
>
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] How can we fix the two-stage page loading problem?

[David Emrany]

Sure Lodewijk,

Banners from December 2016:
https://commons.wikimedia.org/wiki/File:Inline_donor_bannerbass.png
https://upload.wikimedia.org/wikipedia/commons/1/1d/Inline_donor_bannerbass.png

Comments from Seddon
https://lists.wikimedia.org/pipermail/wikimedia-l/2016-December/085612.html

Perhaps these banners were muted for logged-in users in USA, but I was
in S-E Asia last December and it was a very unpleasant experience for
me, especially while on mobile and logged in, to get a begging
banner/pop-up about after every 4 pages I loaded.

David

On 9/6/17, Lodewijk  wrote:
> Hi David,
>
> Would you mind elaborating on the first point? I vaguely recall test
> banners being shown to logged in users, but don't recall seeing one myself
> while logged in for a while.
>
> Best,
> Lodewijk
>
> On Tue, Sep 5, 2017 at 2:16 PM, David Emrany  wrote:
>
>> a) This is incorrect
>> b) how many years would "for several years" encompass?
>>
>> David
>>
>> On 9/5/17, Joseph Seddon  wrote:
>> > WMF hasn't shown fundraising banners to logged in users for several
>> years.
>> >
>> > Regards
>> > Seddon
>>

___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] How can we fix the two-stage page loading problem?

[Andy Mabbett]

On 2 September 2017 at 02:09, Michael Peel  wrote:

> This is possibly the most annoying feature of the Wikimedia projects at the
> moment. You access a page. Then you start reading or editing it. And then
> suddenly the page jumps when a fundraising banner / central notice /
> gadget / beta feature loads.

Yes, very annoying.

The new syntax highlighter, in Beta, (the last time I looked) badly
compounds this.

___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] How can we fix the two-stage page loading problem?

[Lodewijk]

Hi David,

Would you mind elaborating on the first point? I vaguely recall test
banners being shown to logged in users, but don't recall seeing one myself
while logged in for a while.

Best,
Lodewijk

On Tue, Sep 5, 2017 at 2:16 PM, David Emrany  wrote:

> a) This is incorrect
> b) how many years would "for several years" encompass?
>
> David
>
> On 9/5/17, Joseph Seddon  wrote:
> > WMF hasn't shown fundraising banners to logged in users for several
> years.
> >
> > Regards
> > Seddon
>
> ___
> Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/
> wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/
> wiki/Wikimedia-l
> New messages to: Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
>
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] How can we fix the two-stage page loading problem?

[David Emrany]

a) This is incorrect
b) how many years would "for several years" encompass?

David

On 9/5/17, Joseph Seddon  wrote:
> WMF hasn't shown fundraising banners to logged in users for several years.
>
> Regards
> Seddon

___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] How can we fix the two-stage page loading problem?

[Joseph Seddon]

WMF hasn't shown fundraising banners to logged in users for several years.

Regards
Seddon



On 5 Sep 2017 08:33, "Lodewijk"  wrote:

> Hey Ori,
>
> I like the creative thinking :) For the fundraising that could indeed work
> well (although I have no numbers on what percentage of domations comes from
> logged in users etc), but there are also campaigns tht are quite relevant
> for logged in users.
>
> Lodewijk
>
> On Sun, Sep 3, 2017 at 7:16 PM, Ori Livneh  wrote:
>
> > On Sep 3, 2017 13:02, "David Gerard"  wrote:
> >
> > On 2 September 2017 at 02:09, Michael Peel  wrote:
> >
> > > This is possibly the most annoying feature of the Wikimedia projects at
> > the moment. You access a page. Then you start reading or editing it. And
> > then suddenly the page jumps when a fundraising banner / central notice /
> > gadget / beta feature loads. So you have to start reading the page again,
> > or you have to find where you were editing again, or you have to undo the
> > change you just made since you made it in the wrong part of the page.
> >
> >
> > Or you click "edit" and it hits the banner that suddenly popped up
> > under your click. 
> >
> >
> > One possible solution would be to exempt anyone who edits an article from
> > being shown a banner by means of a cookie with a suitable expiry. Since
> > only a tiny fraction of visitors edit, I would expect the impact on the
> > WMF's bottom line to be negligible.
> > ___
> > Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/
> > wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/
> > wiki/Wikimedia-l
> > New messages to: Wikimedia-l@lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > 
> >
> ___
> Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/
> wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/
> wiki/Wikimedia-l
> New messages to: Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] How can we fix the two-stage page loading problem?

[Lodewijk]

Hey Ori,

I like the creative thinking :) For the fundraising that could indeed work
well (although I have no numbers on what percentage of domations comes from
logged in users etc), but there are also campaigns tht are quite relevant
for logged in users.

Lodewijk

On Sun, Sep 3, 2017 at 7:16 PM, Ori Livneh  wrote:

> On Sep 3, 2017 13:02, "David Gerard"  wrote:
>
> On 2 September 2017 at 02:09, Michael Peel  wrote:
>
> > This is possibly the most annoying feature of the Wikimedia projects at
> the moment. You access a page. Then you start reading or editing it. And
> then suddenly the page jumps when a fundraising banner / central notice /
> gadget / beta feature loads. So you have to start reading the page again,
> or you have to find where you were editing again, or you have to undo the
> change you just made since you made it in the wrong part of the page.
>
>
> Or you click "edit" and it hits the banner that suddenly popped up
> under your click. 
>
>
> One possible solution would be to exempt anyone who edits an article from
> being shown a banner by means of a cookie with a suitable expiry. Since
> only a tiny fraction of visitors edit, I would expect the impact on the
> WMF's bottom line to be negligible.
> ___
> Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/
> wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/
> wiki/Wikimedia-l
> New messages to: Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
>
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] How can we fix the two-stage page loading problem?

[Nick Wilson (Quiddity)]

There are 4 or more different problems being discussed here, and it
would be helpful to be precise about each of them, and keep them
separate because they are technically distinct, despite being
thematically linked. (Note: I'm not a dev, which both helps me
simplify the explanation, but also means there might be errors or
over-simplifications!)

-

1. Basic page links, with Banner notices (Central/Site/Geo/Watchlist):
Example: Everyone in Venezuela should be seeing this WLM banner currently:
https://meta.wikimedia.org/w/index.php?title=Main_Page=wlm_2017_ve=1
Problem: These push down the "page content", by the height of the
banner. The desired page content is usually still visible, but it is
still annoying whether reading or trying to click on page content
links.
Cause 1: The geo-targetting javascript takes time to complete. The
only way we could prevent this, is to delay the visibility of the
entire page, for everyone in the world, whilst the code checks whether
or not the reader is in the defined geographic region.
Cause 2: The other javascript takes time to complete. Same as 1, but
for non-geo-targeted notices. (E.g. notices only shown to logged-in
editors with more than 1000 edits.) This is faster, but still takes
time, and per Krinkle's explanation above it is not done until the
page contents are displayed.

-

2. #subsection-links with page bump issues:

2a) Example - banners (as above):
https://meta.wikimedia.org/w/index.php?title=Wikimedia_News=wlm_2017_ve=1#September_2017
Problem: These push *down* the "page content", *in some browsers*

2b) Example - collapsed sections/tables above the link-target:
https://en.wikipedia.org/wiki/Ant#Relationship_with_humans
Problem: These push *up* the "page content", *in some browsers*.
Sometimes they push it up a *lot*. This means it is above the visible
area, which is both annoying and confusing.

Details:
In Chrome/Chromium these links work fine, even if you have fancy
gadgets like "Improved appearance for mobile, narrow and wide screens"
enabled, because Chrome/Chromium uses "scroll-anchoring".
In Firefox, these links get the "page bump" problem. Firefox's
upstream bug: https://bugzilla.mozilla.org/show_bug.cgi?id=43114

---

3. Gadgets and features that are added to the site's User Interface
(userlinks (personal bar), pagelinks (vector's tab bar), sitelinks
(sidebar), etc):
Example: In the Vector skin, the gadget Twinkle adds its "TW"
dropdown-menu tab to the right (in LTR languages) of the
"vector-more-actions" dropdown-menu tab, but it doesn't appear until a
few seconds after the rest of the page loads.
Cause: Per Krinkle's explanation, the JavaScript is done after the
page content has finished loading.
Solution 1: [layout-change] - We could simply move the "TW"
dropdown-menu tab so that it appears in a slightly less-logical place,
i.e. to the left (in LTR languages) of the "Read" tab. (per Doc James
proposal)
Solution 2: [code-change] - I think there might be further
JavaScript/ResourceLoader tweaks that could be done here, but I'm not
sure.



4. Gadgets and features that change the wikitext editing textarea:
Example: In the 2010 wikitext editor, if the "Advanced" or "Special
characters" or "Help" sections were expanded in the previous editing
session, then they will be expanded in your next editing session.
However but they won't "open" until after everything else has loaded.
Cause: ? (I haven't stumbled across the details on this one, yet.)



TLDR: These are all old problems.
Lumping them all together (as this thread is doing, and as quite a few
phabricator tasks do, e.g. T138177) leads to confusing/frustrating
discussions.
Over the years, the possible solutions change for each of these
issues, due to external browser evolution and internal
code-infrastructure evolution - but solving it for older browsers
makes everything complicated (i.e. Firefox could fix their bug today,
but it would only help users who updated their browser), and IIUC
supporting older gadgets/extensions also makes everything complicated
(i.e. we try not to create "breaking changes").
These issues annoy everyone. If they were easy to fix, they would've
been fixed. The developers regularly discuss the issues, and improve
what they can.


On Sun, Sep 3, 2017 at 10:44 AM, James Heilman  wrote:
> These issues can be fixed. Have the banners load below the buttons we
> typically click on. Move the gadgets to the left of "read" rather than to
> the right of "view history". I have proposed this for TW as I mentioned here
>
> https://en.wikipedia.org/wiki/Wikipedia_talk:Twinkle#Button_load_issues
>
> J
>
> On Sun, Sep 3, 2017 at 11:01 AM, David Gerard  wrote:
>
>> On 2 September 2017 at 02:09, Michael Peel  wrote:
>>
>> > This is possibly the most annoying feature of the Wikimedia projects at
>> the moment. You access a page. Then you start reading or editing it. And
>> then suddenly 

Re: [Wikimedia-l] How can we fix the two-stage page loading problem?

[Risker]

Just noting in passing that ascribing this to the gadgets that make up a
personal profile...isn't always what is the problem.  I don't think
standard non-logged-in profile has any of these finicky bits, yet the same
thing happens to users who are not logged in.  All the time - half the time
I find out about an overarching banner, it's from someone who knows I "do"
Wikipedia, and they're complaining to me. I have to disabuse them of the
idea that any editor is likely to be able to change this...

Risker/Anne

On 3 September 2017 at 13:44, James Heilman  wrote:

> These issues can be fixed. Have the banners load below the buttons we
> typically click on. Move the gadgets to the left of "read" rather than to
> the right of "view history". I have proposed this for TW as I mentioned
> here
>
> https://en.wikipedia.org/wiki/Wikipedia_talk:Twinkle#Button_load_issues
>
> J
>
> On Sun, Sep 3, 2017 at 11:01 AM, David Gerard  wrote:
>
> > On 2 September 2017 at 02:09, Michael Peel  wrote:
> >
> > > This is possibly the most annoying feature of the Wikimedia projects at
> > the moment. You access a page. Then you start reading or editing it. And
> > then suddenly the page jumps when a fundraising banner / central notice /
> > gadget / beta feature loads. So you have to start reading the page again,
> > or you have to find where you were editing again, or you have to undo the
> > change you just made since you made it in the wrong part of the page.
> >
> >
> > Or you click "edit" and it hits the banner that suddenly popped up
> > under your click. 
> >
> >
> > - d.
> >
> > ___
> > Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/
> > wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/
> > wiki/Wikimedia-l
> > New messages to: Wikimedia-l@lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > 
> >
>
>
>
> --
> James Heilman
> MD, CCFP-EM, Wikipedian
>
> The Wikipedia Open Textbook of Medicine
> ___
> Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/
> wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/
> wiki/Wikimedia-l
> New messages to: Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
>
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] How can we fix the two-stage page loading problem?

[James Heilman]

These issues can be fixed. Have the banners load below the buttons we
typically click on. Move the gadgets to the left of "read" rather than to
the right of "view history". I have proposed this for TW as I mentioned here

https://en.wikipedia.org/wiki/Wikipedia_talk:Twinkle#Button_load_issues

J

On Sun, Sep 3, 2017 at 11:01 AM, David Gerard  wrote:

> On 2 September 2017 at 02:09, Michael Peel  wrote:
>
> > This is possibly the most annoying feature of the Wikimedia projects at
> the moment. You access a page. Then you start reading or editing it. And
> then suddenly the page jumps when a fundraising banner / central notice /
> gadget / beta feature loads. So you have to start reading the page again,
> or you have to find where you were editing again, or you have to undo the
> change you just made since you made it in the wrong part of the page.
>
>
> Or you click "edit" and it hits the banner that suddenly popped up
> under your click. 
>
>
> - d.
>
> ___
> Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/
> wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/
> wiki/Wikimedia-l
> New messages to: Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
>



-- 
James Heilman
MD, CCFP-EM, Wikipedian

The Wikipedia Open Textbook of Medicine
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] How can we fix the two-stage page loading problem?

[David Gerard]

On 2 September 2017 at 02:09, Michael Peel  wrote:

> This is possibly the most annoying feature of the Wikimedia projects at the 
> moment. You access a page. Then you start reading or editing it. And then 
> suddenly the page jumps when a fundraising banner / central notice / gadget / 
> beta feature loads. So you have to start reading the page again, or you have 
> to find where you were editing again, or you have to undo the change you just 
> made since you made it in the wrong part of the page.


Or you click "edit" and it hits the banner that suddenly popped up
under your click. 


- d.

___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] How can we fix the two-stage page loading problem?

[Peter Southwood]

Is it not possible to display a warning immediately that more things are going 
to load, so that one waits until it is all done?
Cheers,
Peter

-Original Message-
From: Wikimedia-l [mailto:wikimedia-l-boun...@lists.wikimedia.org] On Behalf Of 
James Salsman
Sent: Sunday, 03 September 2017 6:44 PM
To: Wikimedia Mailing List
Subject: Re: [Wikimedia-l] How can we fix the two-stage page loading problem?

Can't we render each gadget in a Foundation-controlled  with a height 
taller than the gadget ever typically flows to?



On Mon, Sep 4, 2017 at 12:00 AM, Krinkle <krinklem...@gmail.com> wrote:
> Hi Mike,
>
> Unexpected page jumps are never fun. They tend to be known as a 
> "reflow" or FOUC [1], and are common all over the web at different times.
>
> Unfortunately, while there may be multiple gadgets / features 
> exhibiting this undesired behaviour, it is not a general problem or 
> limitation. As such, at the infrastructure level, no amount resourcing 
> can make this class of bugs go away.
>
> In a nutshell, there are two primary ways to modify the page of a web site:
>
> * Styling rules (CSS): A declarative way to define rules for how 
> certain page elements should look. (E.g. any "header" should be 
> "blue".)
> * JavaScript programming (JS): A way to provide and execute any 
> arbitrary program code. Including the ability to create new elements, 
> create interactions, and even build entirely new applications.
>
> The styling rules are declarative and can be loaded and applied by the 
> web browser before any content is shown. They apply continuously and 
> retroactively. As such, most websites (including MediaWiki) do made 
> the decision that it is worth delaying the initial show of article 
> content by first loading all style rules (including those from 
> Gadgets). That way, the initial show will consider all style rules 
> from the start. (Instead of starting with unstyled plain text from the 
> top left corner, and progressively applying each style as we go).
>
> The program code, on the other hand, is by design mostly asynchronous 
> and cannot happen "instantaneously" (much like downloading something, 
> or starting an application, or performing a computationally involved action).
> The program itself is in control of how and what it shows visually. It 
> is in charge of whether to show individual pieces directly as they 
> complete, or to insert everything at once after everything is 
> complete. That is up to individual programs to decide.
>
> For developers, it is best practice to never insert or modify visual 
> elements on the page from program code, unless their layout space is 
> reserved ahead of time from HTML or CSS - precisely to avoid reflows. 
> To my knowledge, there are no reflows on regular article views caused 
> by MediaWiki core, nor any of the Wikimedia-maintained extensions 
> (with the notable exception of certain CentralNotice banners, tracked as [2]).
>
> Some experimental Beta Features may have shipped in the past with a 
> reflow bug, but these can (and for the most part, have) been addressed.
>
> That leaves Gadgets, and in that context, this is mostly limited by 
> volunteer resourcing and program quality. Finding the right balance 
> between style rules and program code is not always easy. It is 
> typically easier to write program code without style rules. And as 
> such, some users do it without. I've been in that situation myself as 
> volunteer developer. With limited time, I can either spend time making 
> the actual feature work better after you click it, or spend time 
> avoiding a reflow. With more time, eventually things improve. But this 
> is a bug for individual features or gadgets to address. There is not 
> much we can do about it at the infrastructure level. When the style rules 
> aren't there, they aren't there.
> And when a program later adds an element to the page, you'll want the 
> web browser to show that in the same way as if it was there all along 
> - which means other content essentially moves or jumps out of the way.
>
> For common use cases (like adding sidebar links or tabs), it may be 
> possible to establish conventions that are easy to re-use so that 
> people don't have to spend as much time thinking up new style rules. 
> But overall, each use case will require its own style rule one way or another.
>
> -- Krinkle
>
> [1] https://en.wikipedia.org/wiki/Flash_of_unstyled_content
> [2] https://phabricator.wikimedia.org/T52865 - CentralNotice: Page 
> content shifts
>
> Michael Peel wrote:
>>
>> This is possibly the most annoying feature of the Wikimedia projects 
>> at
> the moment. You access a page. Then you start reading or editing it. 
&g

Re: [Wikimedia-l] How can we fix the two-stage page loading problem?

[James Salsman]

Can't we render each gadget in a Foundation-controlled  with a
height taller than the gadget ever typically flows to?



On Mon, Sep 4, 2017 at 12:00 AM, Krinkle  wrote:
> Hi Mike,
>
> Unexpected page jumps are never fun. They tend to be known as a "reflow" or
> FOUC [1], and are common all over the web at different times.
>
> Unfortunately, while there may be multiple gadgets / features exhibiting
> this undesired behaviour, it is not a general problem or limitation. As
> such, at the infrastructure level, no amount resourcing can make this class
> of bugs go away.
>
> In a nutshell, there are two primary ways to modify the page of a web site:
>
> * Styling rules (CSS): A declarative way to define rules for how certain
> page elements should look. (E.g. any "header" should be "blue".)
> * JavaScript programming (JS): A way to provide and execute any arbitrary
> program code. Including the ability to create new elements, create
> interactions, and even build entirely new applications.
>
> The styling rules are declarative and can be loaded and applied by the web
> browser before any content is shown. They apply continuously and
> retroactively. As such, most websites (including MediaWiki) do made the
> decision that it is worth delaying the initial show of article content by
> first loading all style rules (including those from Gadgets). That way, the
> initial show will consider all style rules from the start. (Instead of
> starting with unstyled plain text from the top left corner, and
> progressively applying each style as we go).
>
> The program code, on the other hand, is by design mostly asynchronous and
> cannot happen "instantaneously" (much like downloading something, or
> starting an application, or performing a computationally involved action).
> The program itself is in control of how and what it shows visually. It is
> in charge of whether to show individual pieces directly as they complete,
> or to insert everything at once after everything is complete. That is up to
> individual programs to decide.
>
> For developers, it is best practice to never insert or modify visual
> elements on the page from program code, unless their layout space is
> reserved ahead of time from HTML or CSS - precisely to avoid reflows. To my
> knowledge, there are no reflows on regular article views caused by
> MediaWiki core, nor any of the Wikimedia-maintained extensions (with the
> notable exception of certain CentralNotice banners, tracked as [2]).
>
> Some experimental Beta Features may have shipped in the past with a reflow
> bug, but these can (and for the most part, have) been addressed.
>
> That leaves Gadgets, and in that context, this is mostly limited by
> volunteer resourcing and program quality. Finding the right balance between
> style rules and program code is not always easy. It is typically easier to
> write program code without style rules. And as such, some users do it
> without. I've been in that situation myself as volunteer developer. With
> limited time, I can either spend time making the actual feature work better
> after you click it, or spend time avoiding a reflow. With more time,
> eventually things improve. But this is a bug for individual features or
> gadgets to address. There is not much we can do about it at the
> infrastructure level. When the style rules aren't there, they aren't there.
> And when a program later adds an element to the page, you'll want the web
> browser to show that in the same way as if it was there all along - which
> means other content essentially moves or jumps out of the way.
>
> For common use cases (like adding sidebar links or tabs), it may be
> possible to establish conventions that are easy to re-use so that people
> don't have to spend as much time thinking up new style rules. But overall,
> each use case will require its own style rule one way or another.
>
> -- Krinkle
>
> [1] https://en.wikipedia.org/wiki/Flash_of_unstyled_content
> [2] https://phabricator.wikimedia.org/T52865 - CentralNotice: Page content
> shifts
>
> Michael Peel wrote:
>>
>> This is possibly the most annoying feature of the Wikimedia projects at
> the moment. You access a page. Then you start reading or editing it. And
> then suddenly the page jumps when a fundraising banner / central notice /
> gadget / beta feature loads. So you have to start reading the page again,
> or you have to find where you were editing again, or you have to undo the
> change you just made since you made it in the wrong part of the page.
>> I understand that this isn't intentional. Presumably there is a
> phabricator ticket about this. But how can we fix this - does this need
> more developer time, is this an external problem that we need someone else
> to fix, or is this a WONTFIX?
>> Thanks,
>> Mike
> ___
> Wikimedia-l mailing list, guidelines at: 
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
> 

Re: [Wikimedia-l] How can we fix the two-stage page loading problem?

[Krinkle]

Hi Mike,

Unexpected page jumps are never fun. They tend to be known as a "reflow" or
FOUC [1], and are common all over the web at different times.

Unfortunately, while there may be multiple gadgets / features exhibiting
this undesired behaviour, it is not a general problem or limitation. As
such, at the infrastructure level, no amount resourcing can make this class
of bugs go away.

In a nutshell, there are two primary ways to modify the page of a web site:

* Styling rules (CSS): A declarative way to define rules for how certain
page elements should look. (E.g. any "header" should be "blue".)
* JavaScript programming (JS): A way to provide and execute any arbitrary
program code. Including the ability to create new elements, create
interactions, and even build entirely new applications.

The styling rules are declarative and can be loaded and applied by the web
browser before any content is shown. They apply continuously and
retroactively. As such, most websites (including MediaWiki) do made the
decision that it is worth delaying the initial show of article content by
first loading all style rules (including those from Gadgets). That way, the
initial show will consider all style rules from the start. (Instead of
starting with unstyled plain text from the top left corner, and
progressively applying each style as we go).

The program code, on the other hand, is by design mostly asynchronous and
cannot happen "instantaneously" (much like downloading something, or
starting an application, or performing a computationally involved action).
The program itself is in control of how and what it shows visually. It is
in charge of whether to show individual pieces directly as they complete,
or to insert everything at once after everything is complete. That is up to
individual programs to decide.

For developers, it is best practice to never insert or modify visual
elements on the page from program code, unless their layout space is
reserved ahead of time from HTML or CSS - precisely to avoid reflows. To my
knowledge, there are no reflows on regular article views caused by
MediaWiki core, nor any of the Wikimedia-maintained extensions (with the
notable exception of certain CentralNotice banners, tracked as [2]).

Some experimental Beta Features may have shipped in the past with a reflow
bug, but these can (and for the most part, have) been addressed.

That leaves Gadgets, and in that context, this is mostly limited by
volunteer resourcing and program quality. Finding the right balance between
style rules and program code is not always easy. It is typically easier to
write program code without style rules. And as such, some users do it
without. I've been in that situation myself as volunteer developer. With
limited time, I can either spend time making the actual feature work better
after you click it, or spend time avoiding a reflow. With more time,
eventually things improve. But this is a bug for individual features or
gadgets to address. There is not much we can do about it at the
infrastructure level. When the style rules aren't there, they aren't there.
And when a program later adds an element to the page, you'll want the web
browser to show that in the same way as if it was there all along - which
means other content essentially moves or jumps out of the way.

For common use cases (like adding sidebar links or tabs), it may be
possible to establish conventions that are easy to re-use so that people
don't have to spend as much time thinking up new style rules. But overall,
each use case will require its own style rule one way or another.

-- Krinkle

[1] https://en.wikipedia.org/wiki/Flash_of_unstyled_content
[2] https://phabricator.wikimedia.org/T52865 - CentralNotice: Page content
shifts

Michael Peel wrote:
>
> This is possibly the most annoying feature of the Wikimedia projects at
the moment. You access a page. Then you start reading or editing it. And
then suddenly the page jumps when a fundraising banner / central notice /
gadget / beta feature loads. So you have to start reading the page again,
or you have to find where you were editing again, or you have to undo the
change you just made since you made it in the wrong part of the page.
> I understand that this isn't intentional. Presumably there is a
phabricator ticket about this. But how can we fix this - does this need
more developer time, is this an external problem that we need someone else
to fix, or is this a WONTFIX?
> Thanks,
> Mike
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Re: [Wikimedia-l] How can we fix the two-stage page loading problem?

[James Heilman]

I just put forwards a proposal to fix part of this issue Mike :-)

https://en.wikipedia.org/wiki/Wikipedia_talk:Twinkle#Button_load_issues

The TW button is easy to fix at least I am told, once I get consensus. Amir
fixed one of the buttons earlier today.

James

On Fri, Sep 1, 2017 at 7:09 PM, Michael Peel  wrote:

> This is possibly the most annoying feature of the Wikimedia projects at
> the moment. You access a page. Then you start reading or editing it. And
> then suddenly the page jumps when a fundraising banner / central notice /
> gadget / beta feature loads. So you have to start reading the page again,
> or you have to find where you were editing again, or you have to undo the
> change you just made since you made it in the wrong part of the page.
>
> I understand that this isn't intentional. Presumably there is a
> phabricator ticket about this. But how can we fix this - does this need
> more developer time, is this an external problem that we need someone else
> to fix, or is this a WONTFIX?
>
> Thanks,
> Mike
>
>
> ___
> Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/
> wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/
> wiki/Wikimedia-l
> New messages to: Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 




-- 
James Heilman
MD, CCFP-EM, Wikipedian

The Wikipedia Open Textbook of Medicine
___
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and 
https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,