Related bug 26234, which is about page anchors not correctlyworking because of the shifting.

mwalker wrote:

I'll give you points for coming up with a solution that works for large screen resolutions but as you pointed out it doesn't work so amazingly for small resolutions.

Sadly it also only works for those banners which are 'standard' and in page. Fundraising banners which take up all of the top will also cause a bounce... :(

We are aware of the issue and we keep taking steps in an attempt to reduce the 'time to bounce' but the only way to eliminate it completely, for generic banners, is to add the banner at page render time or via injection in the caching layer.

We've addressed this very issue in the past by optimizing our delivery workflow but we obviously still have work to do.

What if we put in a timer that said after 0.x seconds after page load we 'slide' in the content rather that just showing it immediately? That would at least give you some warning that it's coming.

Proof of concept of CentralNotice banner that would be both: More visible and implementable without messing with page layout.

Actually I like sliding even less. I'm no friend of dynamic page content at all as you might have noticed.

Sort of fundamental question:
Is the current layout fixed (e.g. should it be considered as a design constraint) or could we freely edit it?

In the latter case see my attachment for a rough design proposal how the banner could be changed to nicely fit into the currently existing space without the need to mess with page layout.

• The banner is at the top of the page (where important banners belong), therefore highly visible.
• The banner is not longer part of the "#content" div (were it doesn't belong) and it is not necessary to mess with the layout to make room for it.
• The banner only shows a heading by default. Therefore one can quickly see if the notice is relevant and expand it as necessary while it only has a small footprint when one isn't interested.
• The extended banner could extend even further to the bottom and to the right to allow for large messages with far more text (currently all information needs to always be hidden behind a link, since no more information would fit into the space offered by the current banner).

I hop you like my way to "think different" since the current design is far from optimal (as you say yourself, there is no clean solution to prevent shifting). Maybe this might be a slight indication of poor design after all? My proposal seems to solve the problem completely while even improving upon current design (at least in my opinion).

Attached:

I, sadly, don't have much to add here. This is, literally, one of the longest running discussions on central notice (if not the longest running one) we've made the bump much better but it is not going to be perfect. You are correct, your design would be nice for the bump and it's certainly an option for people to use but it is unlikely to become the default people use. It's benefits for you (less annoying, only showing a header, need to click to see the rest) are also the weaknesses for some of those showing the banner (less annoying, significantly less see it and find out more).

In the end that is a possibility in the current (though not default) CN system and I would personally prefer to see it used more often but I have to be honest and say I wouldn't use it for things that I 'really' wanted people to see. I've found that small banners like that are just too easily ignored with banner blindness and people move on.

I think coming up with creative ways to do the banner is very helpful, but in the end this is more of a selling process of convincing those who use the banner (both community and staff) to use them. In the end I would prefer to try and find a way to lessen or eliminate the bump, but I also know that we have been working on it for years off and on without finding a great answer and it is not going to happen overnight.

To be clear the biggest problem, by far, that I've seen as we've inspected this in the past is the geolocation. Because we don't know where the user is from right away there is a delay as the page finds out WHERE they are and then has to decide what banner to show.

In T52865#554088, @Jalexander wrote:

To be clear the biggest problem, by far, that I've seen as we've inspected this in the past is the geolocation. Because we don't know where the user is from right away there is a delay as the page finds out WHERE they are and then has to decide what banner to show.

This is a symptom, not a cause. All this work could be done on the server.

In T52865#2393116, @ori wrote:

In T52865#554088, @Jalexander wrote:

To be clear the biggest problem, by far, that I've seen as we've inspected this in the past is the geolocation. Because we don't know where the user is from right away there is a delay as the page finds out WHERE they are and then has to decide what banner to show.

This is a symptom, not a cause. All this work could be done on the server.

And this work now, is, being done on the server. This information is now stored in the GeoIP cookie. The same way we auto-set this cookie in Varnish on outgoing responses, we could also - on incoming requests - transfer it from cookie to a custom in-bound header (and similarly compute when absent).

The real cause then becomes the fact that our page views are statically cached in Varnish without a lightweight composition service in-between the user and the page HTML cache. This is T106099: RFC: Page composition using service workers and server-side JS fall-back.

In T52865#3253998, @Krinkle wrote:

The real cause then becomes the fact that our page views are statically cached in Varnish without a lightweight composition service in-between the user and the page HTML cache. This is T106099: RFC: Page composition using service workers and server-side JS fall-back.

That'll be nice!!

(Just to note, though, the decision about whether or not to show a banner involves a lot of information that's only available on the client, that we wouldn't transmit to the server for privacy reasons.)

Chrome 56+ implements scroll anchoring (explainer, spec, caniuse) which should in theory solve this problem: the browser selects an anchor element (more or less the first element that's visible in the viewport) and on content change the viewport is fixed to that element instead of the top edge of the document.

Well, it solves the aspect of the problem when visiting a section and then the page jumps because some banner appeared outside your viewport and you have no idea what's going on.
Misclicks when your viewport was positioned at the top of the document when the banner loaded would not be prevented.

In T52865#3411980, @Tgr wrote:

Chrome 56+ implements scroll anchoring (explainer, spec, caniuse) which should in theory solve this problem

Yeah! I wonder if and when other browsers will follow... (Here's a Mozilla bug.)

Misclicks when your viewport was positioned at the top of the document when the banner loaded would not be prevented.

Hmmm good point. Yeah, I think there would still be a use case for some sort of animation... maybe an overlay to prevent clicks for the first 1-2 seconds?

Just want to bring to your attention that some banners [1] also tend to jump two times: 1) on the loading phase of JavaScript, and 2) after images are loaded. This should be even more annoying for end users (especially on the slower connections), so maybe we can do something about this? For example, it would be helpful to require CentralNotice admins to set all proportions for images in some way (via CSS or in <img> tag) before releasing the banner so that the box itself would render and stay in one size while loading its content.

[1]: e. g., https://meta.wikimedia.org/wiki/Special:CentralNoticeBanners/edit/wlm_2017