[Jetpack App Migration] Update App Banner Branding

[SiobhyB]

Context: Following the plans to refocus the WordPress apps on core features, we plan to move features that are specific to WordPress.com to the Jetpack app. As such, we will eventually replace all mentions of the WordPress app in Calypso with Jetpack.

Proposed Changes

This PR updates the app banners that are displayed in the Reader, Notifications, Stats, and editor via the mobile web. References to the WordPress app are updated to Jetpack, and the opportunity has also been taken to update the banner's design.

Before	After

Note, the banner's links won't lead to the Jetpack app with this iteration. This PR is mainly focused on updating the banner's design and the groundwork necessary for the links to work in the future.

I've given an overview of the code changes in the sections below (click each section's heading for more).

Banner UI changes ⤵️

• The jetpack/app-branding feature flag (added in Jetpack App: Add 'jetpack/app-branding' flag #66814) is used to add a new banner that displays when the flag is set to true (currently only for wpcalypso and development builds).
• Note, the feature flag, along with any code related to the WordPress-specific banner, will be removed when we're ready to deploy all web-related changes as part of the Jetpack app migration.
• The new jetpackAppBanner component is similar to the current wordpressAppBanner component, except with changes to the copy, the inclusion of the BannerIcon component, and the addition of the jetpack class name for styling.
• The jetpack class name is currently used to specifically target UI elements in the jetpackAppBanner, but will eventually be removed (along with other styles specific to wordpressAppBanner) when the changes are ready to be shipped to users.

Icon animations ⤵️

• The lottie-web dependency has been added to the package.json and yarn.lock files. This dependency enables the usage of After Effects animations. As the full features of the library aren't used in our case, we're able to import the features we need from lottie-web/build/player/lottie_light for better performance.
• A new animations/app-promo directory has been added to house the animated icons. These include RTL versions of the icons.
• References to the files have been added to the getAppBannerData() function, where they can then be retrieved for use in the banner, depending on the section of the screen the user is on.
• By default, jest doesn't handle canvas properly, which leads to an error in tests when combined with lottie-web. To resolve this, canvas has also been added as a devOnly dependency.

Deep linking ⤵️

• iOS: As per Update App Banner deep links for iOS universal links #26118, the app banner points to apps.wp.com for iOS users. The Jetpack app won't open until we make updates to that site.
• Android: Updates to the URIs have been made here but won't work until some further changes have been made in the Android codebase (PR pending).

Testing Instructions

Prerequisite: The app banner can be viewed via the mobile web (which can also be emulated using browser tools) when navigating directly to the Reader, Stats, Notifications, or the editor. Note, if the banner has previously been dismissed in your browser, it'll be necessary to clear your cache.

The following should be confirmed for both iOS and Android:

• Verify that the banner appears as expected when navigating to the Reader, Stats, Notifications, and the editor.
• For now, the banner's "open" link won't open the Jetpack app (see deep links section above for further details). We should, however, confirm that the links to the WordPress app continue to function as before for users.

It'd also be useful to verify the banner works as expected with the following:

• Different devices of varying sizes, including tablets.
• Different Calypso colour schemes.
• Different locales, including RTL.

Screenshots

LTR/RTL animation comparison ⤵️

LTR	RTL
ltr.mov	rtl.mov

Different sections ⤵️

Reader	Editor

Stats	Notes

Different colour schemes ⤵️

Midnight	Sunrise

Mobile/tablet comparison ⤵️

iPad Air	Landscape

Pre-merge Checklist

• Have you written new tests for your changes?
• Have you tested the feature in Simple (P9HQHe-k8-p2), Atomic (P9HQHe-jW-p2), and self-hosted Jetpack sites (PCYsg-g6b-p2)?
• Have you checked for TypeScript, React or other console errors?
• Have you used memoizing on expensive computations? More info in Memoizing with create-selector and Using memoizing selectors and Our Approach to Data
• Have we added the "[Status] String Freeze" label as soon as any new strings were ready for translation (p4TIVU-5Jq-p2)?

Related to #

[github-actions]

Calypso Live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-41675

Jetpack Cloud live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-41675&env=jetpack

[matticbot]

Here is how your PR affects size of JS and CSS bundles shipped to the user's browser:

App Entrypoints (~44 bytes added 📈 [gzipped])

name                   parsed_size           gzip_size
entry-main                  +234 B  (+0.0%)      +44 B  (+0.0%)
entry-stepper               +126 B  (+0.0%)      +24 B  (+0.0%)
entry-login                 +126 B  (+0.0%)      +24 B  (+0.0%)
entry-gutenboarding         +126 B  (+0.0%)      +24 B  (+0.0%)
entry-domains-landing       +126 B  (+0.0%)      +24 B  (+0.0%)
entry-browsehappy           +126 B  (+0.1%)      +24 B  (+0.1%)

Common code that is always downloaded and parsed every time the app is loaded, no matter which route is used.

Sections (~66 bytes added 📈 [gzipped])

name              parsed_size           gzip_size
gutenberg-editor       +279 B  (+0.1%)      +66 B  (+0.0%)

Sections contain code specific for a given set of routes. Is downloaded and parsed only when a particular route is navigated to.

Async-loaded Components (~48318 bytes added 📈 [gzipped])

name                                  parsed_size             gzip_size
async-load-calypso-blocks-app-banner    +177936 B  (+501.1%)   +48318 B  (+490.1%)

React components that are loaded lazily, when a certain part of UI is displayed for the first time.

Legend

What is parsed and gzip size?

Parsed Size: Uncompressed size of the JS and CSS files. This much code needs to be parsed and stored in memory.
Gzip Size: Compressed size of the JS and CSS files. This much data needs to be downloaded over network.

Generated by performance advisor bot at iscalypsofastyet.com.

[SiobhyB]

👋 @griffbrad, non-urgent ping here.

I'm currently working on an update to the app banner displayed on the mobile web. As per p9oQ9f-1jx-p2, I'm experimenting with using lottie to add an animation to the banner's icon. I'm using the most stripped back version of the library that's available, but still notice an increase of ~490% under this comment's Async-loaded Components section.

I saw you mention at p9oQ9f-1jx-p2#comment-1985 that there shouldn't be as notable a difference if "you’re properly async loading the dependency", which leads me to believe I'm doing something wrong here. Would you perhaps be able to point me to any examples or tips for getting round this? Forgive my ignorance, I've done some digging but it's not immediately clear to me what needs to be done.

Thanks in advance for any insight! 🙇‍♀️

[griffbrad]

I should have been a bit more specific there: having that increase under “Async-loaded Components” is actually exactly what you’re aiming for! The concerning outcome would be the increase showing up under “App Entrypoints” or “Sections” because that would imply the code was being loaded for all users navigating to those sections rather than async when it was actually needed.

[noahtallen]

The code changes LGTM -- I only tested one of the banners, but it worked well.

I think the main thing to consider moving forward is that this still adds almost 50KB just to the banners. Since we're on mobile, I think we can expect folks to have poor network connections sometimes, and that 50KB could make it more difficult for the banners to render expediently. That could theoretically cause a drop-off in the number of people clicking through the banner.

Just wanted to throw the idea out there as you keep an eye on any stats related to this after deploying it! :)

I guess the bundle will immediately get bigger in production, even if the Jetpack changes aren't enabled yet. So you should be able to see if there's any impact pretty quickly :)

[dcalhoun]

Great work! 🎉 I left a few comments to consider, but none are likely blockers.

Update: I also meant to share I also tested all the banners, everything worked great. 👏🏻

[SiobhyB]

@noahtallen, @dcalhoun, thanks for your thorough reviews and guidance both. I believe I've addressed all your points, but let me know if anything more comes up!

I think the main thing to consider moving forward is that this still adds almost 50KB just to the banners. Since we're on mobile, I think we can expect folks to have poor network connections sometimes, and that 50KB could make it more difficult for the banners to render expediently. That could theoretically cause a drop-off in the number of people clicking through the banner.

I guess the bundle will immediately get bigger in production, even if the Jetpack changes aren't enabled yet. So you should be able to see if there's any impact pretty quickly :)

This is a really good point. If we do find a drop-off or problems in our own testing, it'd probably be worth reverting the animations and falling back to a static icon.

As Shaun is AFK this week, perhaps the next step (pending any further review on the code) could be to merge this so that the changes are available on staging. This would then make it easier to test the banners across different types of networks (as well as make it easier to test other elements, like deep linking). We could then keep an eye on any potentially negative impact and make any updates that come from design feedback in a separate PR. Does that seem like a good route?

[dcalhoun]

🚀 Great work! 👏🏻

One note: I was unable to get the banners to display on a tablet (emulated with Safari or Chrome developer tools). This was also the case for the production environment, so it appears unrelated to this PR. My guess is that we only display the banners for screens below a certain width. Did you experience this?

As Shaun is AFK this week, perhaps the next step (pending any further review on the code) could be to merge this so that the changes are available on staging. This would then make it easier to test the banners across different types of networks (as well as make it easier to test other elements, like deep linking). We could then keep an eye on any potentially negative impact and make any updates that come from design feedback in a separate PR. Does that seem like a good route?

This sounds like a good plan to me. 👍🏻

[SiobhyB]

Thank you!

One note: I was unable to get the banners to display on a tablet (emulated with Safari or Chrome developer tools). This was also the case for the production environment, so it appears unrelated to this PR. My guess is that we only display the banners for screens below a certain width. Did you experience this?

Ah, yes, I see you're right! While testing, I'd removed the shouldDisplayAppBanner conditional locally so that the banner was always displayed to me, which is the only reason I was able to test with a tablet emulator. I see that, by default, the banner only displays on mobile devices and tablet testing isn't required. 👍

I'll go ahead to merge now.

[a8ci18n]

This Pull Request is now available for translation here: https://translate.wordpress.com/deliverables/7507145

Thank you @SiobhyB for including a screenshot in the description! This is really helpful for our translators.

[simison]

Just learning about Lottie and I had a question: does the library take into account @media/prefers-reduced-motion setting out of the box or would that need extra attention here?

[dcalhoun]

My understanding is that, no, Lottie does not take into account motion preferences.

You raise a good point. It's an opportunity to improve this new feature. I would imagine we should render the last frame of the animation when reduced motion is preferred.

[SiobhyB]

Thanks for catching this! I'll work on a PR to take reduced animation preferences into account. 🙇‍♀️

[SiobhyB]

To tie up all the loose ends, I've gone ahead to create that PR here: #67826

[shaunandrews]

I tried a few times to get the banner to trigger, and was unsuccessful. However, since you did such an excellent job writing up this PR with a bunch of screenshots, I can still give some feedback!

The only note I have is about the font-weight. I see it's been set to bold for the headings, but it feels a little too bold. Maybe we can go with 500 instead, and/or compare to other uses of Recoleta with bolding in our UI.

[a8ci18n]

Translation for this Pull Request has now been finished.

[SiobhyB]

@shaunandrews, thank you for the feedback! @dcalhoun also spotted some differences between the banner and the initial design you provided in a separate review, so I've gone ahead to create a separate (currently draft) PR with design updates at #67607. While that PR's in draft mode, I'll aim to keep the before/after screenshots up-to-date.

I've changed the title's font-weight from bold with 500 as part of that. I'll aim to set it as ready for review next week and will keep it up-to-date with any extra design feedback you may have. 🙇‍♀️