Site Migration: Show option to get an assisted migration on the migration instructions screen

[andregardi]

Closes #92868

Proposed Changes

We are adding a escape hatch on the DIY migration instruction to reach out to assisted migration flow.
This will help users having a hard time doing the migration themselves.

Testing Instructions

Testing the top right action button

• Start a DIY site migration. Now days it is accessible by the I'll do it myself link on to right of the site-migration-how-to-migrate step.
• Reach the migration instructions step.
• On the top right corner of the page you should see a Having trouble? Let us migrate your site link. Click on it.
• You should be redirected to assisted migration final step.
• A Zendesk ticket for your migration should be created.

Testing error message action button
We are also updating the error message.

Instead of contacting support, we adding a "Let us take it from here" that directs the user to assisted migration.

To make sure you will get an error message I suggest updating your local Calypso file:
client/landing/stepper/declarative-flow/internals/steps-repository/site-migration-instructions/provision-status/index.tsx
On line 67, force the error condition to true.

• Follow the same steps to reach the instructions page.
• Click on "Let us take it from here"
• You should be redirected to assisted migration final step.
• A Zendesk ticket for your migration should be created.

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 UI changes, have we tested the change in various languages (for example, ES, PT, FR, or DE)? The length of text and words vary significantly between languages.
• 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-aUh-p2)?

[github-actions]

Calypso Live (direct link)

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

Jetpack Cloud live (direct link)

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

Automattic for Agencies live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-135183&env=a8c-for-agencies

[matticbot]

This PR modifies the release build for the following Calypso Apps:

For info about this notification, see here: PCYsg-OT6-p2

• notifications
• wpcom-block-editor

To test WordPress.com changes, run install-plugin.sh $pluginSlug update/difm-from-diy on your sandbox.

[matticbot]

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

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

name           parsed_size           gzip_size
entry-stepper        +72 B  (+0.0%)       +3 B  (+0.0%)

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

Sections (~9 bytes added 📈 [gzipped])

name                        parsed_size           gzip_size
site-migration-flow              +121 B  (+0.3%)       +9 B  (+0.1%)
hosted-site-migration-flow       +121 B  (+0.3%)       +9 B  (+0.1%)

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.

[andregardi]

I am adding @fditrapani as reviewer to confirm the copies.

[a8ci18n]

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

Some locales (Hebrew, Japanese) have been temporarily machine-translated due to translator availability. All other translations are usually ready within a few days. Untranslated and machine-translated strings will be sent for translation next Monday and are expected to be completed by the following Friday.

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

[daledupreez]

I think we need to fix the link tracking on this one. I'll take over the PR while @andregardi is out this week, so I won't officially "Request Changes" in the review.

[daledupreez]

Typo: DifmActionrops => DifmActionProps

We've also had previous discussions about using just Props in the name, though we're not exporting it here, so not a major issue on that front.

Also, why an interface and not a strict type? It doesn't feel like we should expect or allow any non-prop arguments.

Suggested change

	interface DifmActionrops {
	navigateToDoItForMe: () => void;
	}
	export const DifmAction: FC< DifmActionrops > = ( { navigateToDoItForMe } ) => {
	const translate = useTranslate();
	interface DifmActionProps {
	navigateToDoItForMe: () => void;
	}
	export const DifmAction: FC< DifmActionProps > = ( { navigateToDoItForMe } ) => {
	const translate = useTranslate();

[daledupreez]

I think we should keep the original event structure so we can differentiate between the two click locations. With the new code, we're going to get exactly the same Tracks event from both clicks, so we won't be able to tell them apart.

[daledupreez]

In thinking about this more, I don't think we should send all users to DIFM if there is an error here. I think they should be allowed to choose between contacting support and requesting an assisted migration.

I also think we need clearer language to make it 100% clear what the user is going to request/do. So I think we need two options here:

• [Contact support]
• [Let us migrate your site]

[daledupreez]

@fditrapani, I started working on this and I realised that showing "Contact Support" and "Let us migrate your site" ends up being pretty unwieldy. I ended up with the following working layouts, but I'd love feedback on both the idea of showing both and the layout I'm exploring before I push my changes into the PR.

You'll notice that I'm using parallel secondary buttons in the desktop layout, and switching to a vertical, center-aligned layout for mobile. The CTAs are also above the error text, which is likely to be correct in most situations.

Desktop

Mobile

[fditrapani]

Thanks for the ping!

I think we can take a slightly different approach in that when this error happens. Instead of updating the messaging in the blue box, can we hide it and replace it with a notice like this:

(Don't mind the spacing as I was working off your screenshots). The approach should work well on desktop + mobile. What do you think?

[daledupreez]

@fditrapani, I explored this a little bit today, and it looks like the Notice component from @wordpress/components has a slightly weird spacing for actions compared to the WordPress Design System -- you can see that in the Storybook here.

Here are some updated screenshots from this PR:

Mobile

I added some CSS for the spacing above the buttons and vertical spacing between the buttons, but this tertiary button style looks a bit weird in the vertical layout.(See the explorations below for screencaps of secondary and link treatments for the "Let us migrate..." action.)

Desktop

Mobile explorations

I explored making the "Let us migrate..." item a link and a secondary button:

Link

Secondary button - mobile and desktop

[fditrapani]

Thanks for looking into this and sharing the screenshots. That's unfortunate about the spacing.

If i had to pick between the two options, I think it would better to go with the link. The two buttons have different border radiuses and they look clunky side by side.

You mentioned being able to adjust the spacing with local overrides. Is that a good call or could it lead to us having issues down the line if they change something in the component? If it's not a problem, I can suggest a few more tweaks to help improve the layout.

[daledupreez]

You mentioned being able to adjust the spacing with local overrides. Is that a good call or could it lead to us having issues down the line if they change something in the component? If it's not a problem, I can suggest a few more tweaks to help improve the layout.

@fditrapani, I don't think we should, to be honest. The implementation for the Notice component is visually poor when actions exist, so I don't think we should pull it in. Might there be another primitive we can/should aim for? Might it be worth looking at the NoticeBanner component in @automattic/components? I have the following screenshot of the component's baseline Warning state from a local version of Storybook:

[fditrapani]

I don't think we should, to be honest

Good call! Thanks for suggesting that component. This is what I see for the Notice banner in our Figma library. Looks like it's slightly out of sync. Something along these lines should work:

[daledupreez]

@fditrapani, I've now reported the spacing problems with the Notice component from @wordpress/components in WordPress/gutenberg#69426 (and it looks like someone has already started a PR!). To be clear, the implementation doesn't match the Figma for the component, so it feels like a straightforward bug.

This is what I see for the Notice banner in our Figma library.

@fditrapani, I think we need to be extremely clear about which library this banner is coming from. I've flagged some issues with the implementation of the Notice component from @wordpress/components, which seems to closely resemble the component you're referring to. We also have a Notice component in Calypso, but that has a dark background and looks completely different. That's why I referenced the NoticeBanner component from @automattic/components, which is at least similar.

If we really want to stick with that component, we can, but it means that we need to add a wrapper component in Calypso, layer on the alternative styles, and then ensure that we remove the wrapper component when the upstream fixes are available in Calypso. That feels like a lot of work to pull this component into this screen. Is there a way for us to flag issues with certain components from @wordpress/components for folks on the WordPress.com design team?

[fditrapani]

Thanks for creating that issue @daledupreez. I agree that we don't want to go down the route of creating extra wrapper components. With the fix happening for the core component can we stick with that one?

Is there a way for us to flag issues with certain components from @wordpress/components for folks on the WordPress.com design team?

We're still lacking some process here but the approach you took is best. Feel free to bring me in on an issue like you created if you need mock ups or design input.

[daledupreez]

With the fix happening for the core component can we stick with that one?

@fditrapani, it's not clear when we'll actually pick up the version of Gutenberg with the fix, so it could be a while before the component itself looks good. That's part of why I wanted to flag it for the design team: the implementation doesn't match the Figma, and probably won't for some amount of time, so we need some way of flagging that it's currently not a great component for the notice + actions use case.

That still leaves us with what to do for this error notice/case. I will split out the top right escape hatch into a separate PR so we can get that moving, and I'll work on implementing a component that mimics the layout you've shown for the error case. (I'll definitely include a note to mention that it should be replaced with the Notice component when the issue has been resolved.)

[fditrapani]

@fditrapani, it's not clear when we'll actually pick up the version of Gutenberg with the fix, so it could be a while before the component itself looks good. That's part of why I wanted to flag it for the design team: the implementation doesn't match the Figma, and probably won't for some amount of time, so we need some way of flagging that it's currently not a great component for the notice + actions use case.

Thank you for doing this. I think you identified a weak point in our general system that I'll bring up with the team. Coincidentally, I came across this comment on another PR.

In this case, the “Notice” component can work. That component itself is actualy not modernized in any way, it’s just a component reimplementation of the classic core notice, so it’s not very good looking. But the perspective is we will eventually improve it, and at that point, it'll be improved in package updates. Though if you use it, maybe use it without the yellow warning color, The vanilla notice should just be white.

Looks like it's a known issue but isn't communicated well as you pointed out.

That still leaves us with what to do for this error notice/case. I will split out the top right escape hatch into a separate PR so we can get that moving, and I'll work on implementing a component that mimics the layout you've shown for the error case. (I'll definitely include a note to mention that it should be replaced with the Notice component when the issue has been resolved.)

That makes sense. Thanks for being flexible here.

[fditrapani]

Just wanted to bring a comment over from another issue. For the Contact support button, if possible, let's see if we can open a direct line to our HEs vs making them go through the AI assistant. These are high value customers.