Change Details

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 [[ https://web.dev/optimize-lcp/ | Largest Contentful Paint ]] (LCP) metric that goes into effect at the same time as [[ https://web.dev/cls/ | 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. - Though small, banners could have a button to expand to show more content. - Due to the foregoing, no options for Fundraising's current large or medium-sized ("small") banners, other than click-a-very-small-banner-to-expand. - 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)//

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 [[ https://web.dev/optimize-lcp/ | Largest Contentful Paint ]] (LCP) metric that goes into effect at the same time as [[ https://web.dev/cls/ | 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 without SEO impact. The closest options for such banners sizes are: - click-a-very-small-banner-to-expand; or - very-small-banner that auto-expands (only overlaying, but not shifting content) 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)//

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 [[ https://web.dev/optimize-lcp/ | Largest Contentful Paint ]] (LCP) metric that goes into effect at the same time as [[ https://web.dev/cls/ | 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: - Though small - 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, banners could have a button to expandto ensure it's small enough to show more contentnot impact LCP. - Due to the foregoing, - 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 without SEO impact. The closest options for such banners sizes are: - click-a-very-small-banner-to-expand; no options for Fundraising's current large or medium-sized ("small") bannersor - very-small-banner that auto-expands (only overlaying, other than click-a-very-small-banner-to-expandbut not shifting content) 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)//