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 <ori.livneh(a)gmail.com> wrote:

WMF hasn't shown fundraising banners to logged in users for several years. Regards Seddon On 5 Sep 2017 08:33, "Lodewijk" <lodewijk(a)effeietsanders.org> 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 <david.emrany(a)gmail.com> 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 <david.emrany(a)gmail.com> wrote:

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 <david.emrany(a)gmail.com> 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 <dgerard(a)gmail.com> wrote: -- James Heilman MD, CCFP-EM, Wikipedian The Wikipedia Open Textbook of Medicine

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&banner=wlm_2017_… 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&banner=wlm_… 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 <jmh649(a)gmail.com> wrote: -- Nick Wilson (Quiddity) Community Liaison, Wikimedia Foundation