[my-wordpress] Updating personal WP welcome modal

[fellyph]

• Applying the WordPress Design System to the Welcome modal
• Cleaning up the error message when the user changes the website url

[brandonpayton]

Thanks for doing this, @fellyph!

One concern I have is:
The current WordPress Components docs for modals show the confirmation buttons right-aligned with the primary/OK button on the right as well.
https://developer.wordpress.org/block-editor/reference-guides/components/modal/

It might be that the WordPress Design System has been updated to recommend something different, but I wasn't able to confirm this while looking at the wpds skill or the underlying MCP server. Maybe it would be good to check w/ the wpds skill about adjusting the alignment and see what it says.

[fellyph]

I have moved the buttons to the right:

[brandonpayton]

Looks like the latest commit has the buttons aligned on the right with the primary button on the right as well. I think this is good to go. Thank you!

[jasmussen]

Hello! Fan of the work. I was brought here on a ping related to design systems, and have a few notes. Let me know where's the best place to share this.

The crux of it is, these are CSS/HTML changes only, they don't appear to be using the WordPress design system at all. It's a bit of an older way of working, and it has the downsides that drift will happen very often, and subtle details that are built-in to the components are hard to capture in the emulation. For example just looking at https://my.wordpress.net:

• It's using the classic blue. It should be blueberry, #3858E9
• Titles should be sentence case with capital proper nouns: "Welcome to your WordPress"
• Buttons and inputs should be 40px tall, or 32, never 36.
• Corner radius of the modal should be 8px
• Icons are 16x16 footprint inside a 24x24 SVG container. That site uses a mix of footprints and container sizes, across 20x20, 26x26, and 24x24.
• It's a mix of icons. I don't recognize the reload, or the drawer. Can potentially instead use rotateRight and drawerLeft from the icon library.

But the thing is, these notes should not be fixed with adjusted CSS or HTML. The blueberry color is the default in the set. The icons have the correct footprints. And adjusting it to look like the design system isn't using the design system: the code is the source of truth, unless you're actually using WordPress components, this is effectively a bespoke implementation.

In that sense, I would recommend a tech+design discussion on what is being built for this project: is it a custom implementation and custom design? Then that should be designed, and a component system chosen for it (I'd certainly recommend a component system to ease implementation in general). But if it's meant to use the WordPress design system, the solution isn't CSS, otherwise it will be an ongoing source of CSS maintenance and feedback on little details that are easy to miss.

This isn't shared in bad faith to diminish the work that's gone on. The tech is cool, this PR was a step in the right direction. But I also want to be clear: building with a design system means using the components. Let me know if this was useful!

[iamtakashi]

@jasmussen Thank you so much for your guidance. This is very helpful. I agree that the modal should utilise the system rather than mimicking it with CSS to avoid higher maintenance costs.

@brandonpayton What do you think? I think utilising the system makes sense. I also consulted the writing team for the copy. Do you need anything else to further improve the modal?

[fellyph]

Thanks @iamtakashi @jasmussen for the feedback. I will open a new pull request with the suggestions.

[brandonpayton]

@jasmussen and @iamtakashi, thank you for your feedback on this. You're totally right that the PR wasn't using the design system. I should have noticed, and we will work to correct that.

note: "You're totally right" sounds a bit too much like a Claude response for my liking, but my response is sincere. 😅

Do I understand correctly that the preferred approach to use the design system is to use the React-based @wordpress/components package in order to take advantage of the builtin styles, colors, and layouts in the WordPress design system?

[jasmussen]

Do I understand correctly that the preferred approach to use the design system is to use the React-based @wordpress/components package in order to take advantage of the builtin styles, colors, and layouts in the WordPress design system?

I'd reframe it a bit and say: the react componentry is the design system, insofar as the code is the source of truth.

So if you're not using those, it's something else. But to be clear: that can also be necessary at times, and the question then becomes whether this needs its own design system or not. What we want to avoid is this in-between that's at risk of drifting. Is that fair?

Thank you for responding. I don't think this is the most urgent thing in the world, but I think it's important to clarify the details that the design system means the code too.