[CYS on Core] Make sure the pre-loader is triggered right after the user clicks on the opt in modal.

[nefeline]

Issue Description:

Whenever the store owner did not give us consent and has the latest version of WP/GB installed, the following message is displayed on the sidebar:

To reproduce, make sure Gutenberg is enabled and/or your version of WordPress is 6.5 (if already available). Also, ensure you did not allow tracking by unchecking the usage tracking box on WooCommerce > Settings > Advanced > Woo.com.

Whenever clicking on the “usage tracking” link, the following modal should open:

Whenever usage tracking is allowed, the page reloads, fonts are installed, and all relevant font pairings are displayed. The problem in this case is that the preloader is being added a bit later in the process, so the user can briefly visualize the fonts cards that are about to be installed when they shouldn't:

Screen.Recording.2024-03-11.at.11.34.16.mov

To improve user experience, let's ensure the pre-loader is triggered right after the user clicks on the opt-in modal so the fonts on the sidebar are visible only after they were downloaded.

[gigitux]

Whenever usage tracking is allowed, the page reloads, fonts are installed, and all relevant font pairings are displayed

We can't rely on the async job. This latter can start later or be slower. Consequently, there's a risk that after refreshing the page, the fonts might not be installed. A potential solution involves installing the fonts on the client side. However, this method presents a challenge: it requires UI blocking (like loading screen) until all fonts are installed, which could lead to extended wait times (btw not the best UX).

The best solution is to provide an async client process so the user can continue to use the Assembler and notify it when the fonts are ready to be used, but I don't think that there is enough time for this kind of experience (also, is it worth investing time on it?)

As the first version, we could redirect the user to the settings page of WooCommerce, and after that, the user will have to restart the process from scratch. I know that it is not an optimal solution, but it is something that we could consider.

Otherwise, we have to find a UI that shows the user that fonts are being installed, but the user can't use the Assembler (like a big loading screen).

This is a video that shows the issue:

92aGzg.mp4

Thoughts?

cc @albarin @nefeline @verofasulo

[nefeline]

Thanks for your input @gigitux !

We can't rely on the async job.

We are not relying on the async job in this case: by triggering the loading screen whenever the "Opt in" button is clicked, we should trigger the validation that ensures all relevant fonts are in place and were successfully installed. - If for some reason these fonts are not available, trigger the fonts installation on the JS side so the store owner have them all available by the time they reach the Assembler. This was in the original scope of implementation as described here: #44257

Are you implying this hasn't been implemented?

[gigitux]

Thanks for your input @gigitux !

We can't rely on the async job.

We are not relying on the async job in this case: by triggering the loading screen whenever the "Opt in" button is clicked, we should trigger the validation that ensures all relevant fonts are in place and were successfully installed. - If for some reason these fonts are not available, trigger the fonts installation on the JS side so the store owner have them all available by the time they reach the Assembler. This was in the original scope of implementation as described here: #44257

Are you implying this hasn't been implemented?

It has been implemented and we can re-use the same function. Just to clarify:

To improve user experience, let's ensure the pre-loader is triggered right after the user clicks on the opt-in modal so the fonts on the sidebar are visible only after they were downloaded.

With the `pre-loader is triggered´, are you referring to this preload screen?

[gigitux]

This is a quick implementation. Are we aiming an experience like this, right?

Screen.Capture.Mar.13.at.20-49.mp4

[nefeline]

This is a quick implementation. Are we aiming an experience like this, right?

It could be like this, yes!

Currently, the Opt-in modal is directing users directly to ${ ADMIN_URL }admin.php?page=wc-admin&path=%2Fcustomize-store%2Fassembler-hub, but we could update that to ${ ADMIN_URL }admin.php?page=wc-admin&path=%2Fcustomize-store%2Fdesign without any problems (while the first is just a regular preloader, the second is the default loading screen we have in the CYS).

https://github.com/woocommerce/woocommerce/blob/trunk/plugins/woocommerce-admin/client/customize-store/assembler-hub/sidebar/sidebar-navigation-screen-typography.tsx#L215

Either way, the most important thing is to ensure that this is triggered:

woocommerce/plugins/woocommerce-admin/client/customize-store/design-without-ai/state-machine.tsx

Line 163 in 69728b7

installFontFamilies: {

And that the loading screen is displayed immediately after the user clicked on "Opt in", without any delays (this is the main goal of this issue!)