Page MenuHomePhabricator

Study options and designs for banner formats to prevent search ranking decline
Open, LowestPublic

Description

This task is about options, possible designs, and tests, for alternate banner formats that don't affect our score on Google's new search ranking metrics (see T280476 for details). Even if an engineering solution is deployed (T279034) we may have to fall back temporarily to options like this.

General considerations

  • Banners would have to be small, because of the Largest Contentful Paint (LCP) metric that goes into effect at the same time as CLS (the metric that the banner bump impacts). LCP will penalize sites when the largest element in the viewport takes a long time to render. So, if a banner is the largest element on a mobile screen, and it renders late (as it does in the current system) our rankings will still take a hit. More details:
    • Since in JS we can measure the size of the viewport and other elements, we can at least check/adjust the size of the banner before injecting client-side, to ensure it's small enough to not impact LCP.
    • LCP stops reporting as soon as the user interacts with the page (including if the user scrolls).
    • Banners can have a button to expand to show more content; this shouldn't impact any metrics.
  • In view of the foregoing, Fundraising's current large- or medium-sized ("small") banners are not possible under the current system, without affecting SEO. The closest options for such banners sizes are:
    • click-a-very-small-banner-to-expand;
    • very-small-banner that auto-expands (overlaying, but not shifting content) after the user starts interacting with the page; or
    • no banner at all, then a banner of any size (again, overlaying, but not shifting content) that appears after the user starts interacting with the page.
  • Reader and editor objections to these possible banner designs may be significant and justified.

Options:

1) Banners overlay content.

  • Usability gets significantly worse.
  • If all banners have to be manually closed to reveal content, readers and editors will surely find it incredibly annoying.
  • Readership might even go down due to the annoyance.

2) Banners are animated and don't need to be closed.

  • This option is like the "nag" elements that Fundraising banners sometimes have when you scroll away from the main banner at the top of the page. Even though you'd still be able to access content, they'd be at least a bit annoying.
  • In addition to having to be to be small to not affect our score on the LCP metric, they would also have to be small enough to not obscure too much actual content.
  • This seems a bit better than the previous option, though objections from readers and editors might still be quite significant.
  • The best version of this category of banner design is probably a small, sticky footer at the bottom of the page. It could appear with an animation once banner content has loaded in the background, and it could slide out of view if the user scrolls and doesn't interact with it after some time.

3) Always reserve space, even if there is no banner.

  • There is a significant danger that users would get used to ignoring whatever's in this space, since it would almost never contain the information they're looking for (though some amount of animation or eye-catching design might help mitigate this).
  • Reserving space like this would probably require reworking the current desktop refresh project, at least to some extent.

(Note: I am working on this on my own time, so, not as part of my work as an FR-Tech engineer. Unless otherwise noted, this task is not included in planned work by FR-Tech. Thanks so so much!! - @AndyRussG)

Event Timeline

(From T279034)

When we look for alternative banner formats that don't cause layout shifts, we know that we have to avoid making it too big, so that instead of being captured by Cumulative Layout Shift, it doesn't end up being captured by Largest Contentful Paint instead.

There is an important factor in the definition of Largest Contentful Paint:

The browser will stop reporting new entries as soon as the user interacts with the page (via a tap, scroll, or keypress

In other words, we could wait for such user interactions to happen before injecting a (non-layout-shift-inducing) banner. Maybe with a little delay so it's not too jarring, but it might work. In this case we wouldn't have to worry about the banner size.

If we want to insert a (non-layout-shift-inducing) banner before user any interaction, we can also consider dynamically sizing it to always be smaller than the biggest element in the viewport. Which, most of the time is the first paragraph, or can be a big thumbnail. We can find via JS which element is the biggest and shrink the banner to be smaller if necessary. Or we can just not display the banner at all if the viewport has such extreme dimensions that even a shrinked banner wouldn't fit without being the biggest element in view.

These mitigation strategies actually work because those banners would be injected with JS and because that injection happens relatively late in the page's initial rendering. Using those infrastructural weaknesses to our advantage.

Thanks @Gilles! Updating the task description to include these considerations.

AndyRussG updated the task description. (Show Details)
DStrine triaged this task as Lowest priority.Apr 22 2021, 11:27 PM
DStrine added a subscriber: DStrine.

The banner team will organize tests and integrate them into the asana schedule. There is no plan to reserve a fixed space for banners. This task isn't needed.

The banner team will organize tests and integrate them into the asana schedule. There is no plan to reserve a fixed space for banners. This task isn't needed.

  • There are also community banners and Fundraising banners for local chapters. Design proposals and tests would also be needed for those.
  • Overall site design, usability and reachability are still potentially impacted by this (even if the reserving space option is not considered). So, I think this involves many teams and concerns beyond Advancement?
  • This is a technically challenging problem; additional input, I hope, could help us find better solutions?
  • Important topics impacting the site and the movement are normally considered through open discussion in spaces like this, often here in Phabricator.

Thanks!!

Peter added a project: Performance-Team.
Peter added a subscriber: Peter.