Congrats: Update design for ecommerce plan

[candy02058912]

Related to https://github.com/Automattic/dotcom-forge/issues/2723

Proposed Changes

Before	After

• Update the design to align with the rest of the plans update
• Added/updated tests

Testing Instructions

1. Upgrade to e-commerce plan through /plans page
2. Check to see the page update on desktop/mobile
3. Click on the buttons
4. Make sure tracks events are present
5. Test around and try to break it

Pre-merge Checklist

• Has the general commit checklist been followed? (PCYsg-hS-p2)
• 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)?
• For changes affecting Jetpack: Have we added the "[Status] Needs Privacy Updates" label if this pull request changes what data or activity we track or use (p4TIVU-ajp-p2)?

[matticbot]

Calypso Live (direct link)

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

Jetpack Cloud live (direct link)

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

[matticbot]

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

Sections (~168 bytes added 📈 [gzipped])

name      parsed_size           gzip_size
checkout       +945 B  (+0.1%)     +168 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.

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.

[matticbot]

This PR modifies the release build for happy-blocks

To test your changes on WordPress.com, run install-plugin.sh happy-blocks update/congrats-plan-ecommerce on your sandbox.

To deploy your changes after merging, see the documentation: PCYsg-r7r-p2

[lsl]

This doesn't look safe to me, AtomicStoreThankYouCard is doing email verification and sets the CTA url to siteWooCommerceWizardUrl, can we wrap StandardCheckoutThankYou inside AtomicStoreThankYouCard and keep the same behavior?

We're also losing the "Create your store!" CTA text. "Lets work on the site" doesn't sound right for the ecommerce plan.

[candy02058912]

This PR also sets the CTA to the same URL as siteWooCommerceWizardUrl.

As for email verification, I tested, and with the current flow, the user will get redirected to another email verification page when clicking on the CTA siteWooCommerceWizardUrl

Once they verify their email and click on connect jetpack, they will go to the store setup page

Summarizing the flow for unverified emails:

How this PR currently changes the flow:

1. Thank You page
2. Click on CTA
3. Verify Email
4. Connect Jetpack (this might be the confusing step)
5. Start setting up the store

The current production flow:

1. Thank You card
2. Verify Email
3. Click on CTA
4. Start setting up the store

Any ideas on how we could incorporate the old flow into the new design
cc: @JanaMW27

[lsl]

How this PR currently changes the flow:

Thank You page
Click on CTA
Verify Email
Connect Jetpack (this might be the confusing step)
Start setting up the store

The current production flow:

Thank You card
Verify Email
Click on CTA
Start setting up the store

How did we add the Jetpack connection step?

Any ideas on how we could incorporate the old flow into the new design

I'd need to dig in to really judge this but I think the new design needs to support the old design's functionality other wise the only option is to revert to the "new" thank you component approach and let them control the flow and we just control the basic design outline.

I guess you could change something higher up to but I don't know how that would work.

What are you thinking?

[lsl]

Oh, also this option looked ok if I'm remembering it correctly:

can we wrap StandardCheckoutThankYou inside AtomicStoreThankYouCard and keep the same behavior?

[candy02058912]

How did we add the Jetpack connection step?

I didn't add anything in particular. It was... just there 😅 when I tested the flow with the PR.
Maybe it would be helpful if we have more people to test the flow within this PR to confirm.

[candy02058912]

What are you thinking?

I was only taking account of how things "look" right now. For example, I'm not sure where would be the sweet spot to add the resend email button or add the copy. Asked for more input here: p9Jlb4-7Hx-p2#comment-8670

I agree that code-wise it's not going to be too far from:

wrap StandardCheckoutThankYou inside AtomicStoreThankYouCard and keep the same behavior?

Even if we create a new component, it's going to copy that behavior.

[JanaMW27]

Here is my proposal to cover both cases:

1/ When the user has not verified their email:

2/ When the user has verified the email:

Figma files can be found here the mobile version

[candy02058912]

Also related to Automattic/wc-calypso-bridge#1252

[candy02058912]

We can remove the part for isWcMobileApp according to https://github.com/Automattic/dotcom-forge/issues/2723#issuecomment-1652777142

[candy02058912]

Closing this PR as @Automattic/serenity has taken over.
Ref: p58i-g5m-p2#comment-60615