There's still lots to do here, but it would be good to get some early design feedback 🙂

Hey @noisysocks! 👋

Happy to help with design feedback. How can I get this to show up on my local install?

Thanks @enriquesanchez! You can check out the branch and then open the Welcome Guide from the More menu:

Would it be possible for the <Guide /> component to be a part of NUX? This looks like something that'd be awesome to use on plugin admin screens as well. But since <Guide /> is in editPost it'd be difficult to use.

Separately, it looks like #12632 would still be effected by this tips redesign. AFAICT, the close button here is dismissing all guides instead of just the current "guide".

Would it be possible for the <Guide /> component to be a part of NUX? This looks like something that'd be awesome to use on plugin admin screens as well. But since <Guide /> is in editPost it'd be difficult to use.

Good suggestion! I'll look into this.

@mapk: Do you think a guide component would be useful outside of WP Admin? If so, then I think we should consider putting Guide and/or GuideModal into @worpdress/components so that we get to use the existing infrastructure there e.g. storybooks.

Separately, it looks like #12632 would still be effected by this tips redesign. AFAICT, the close button here is dismissing all guides instead of just the current "guide".

Thanks for pointing me to #12632. I'll look into moving away from areTipsEnabled(). My preference is to make Guide a dumb component and leave it up to the plugin developer to decide when to show it.

@mapk: Do you think a guide component would be useful outside of WP Admin? If so, then I think we should consider putting Guide and/or GuideModal into @worpdress/components so that we get to use the existing infrastructure there e.g. storybooks.

YES! Adding this to @wordpress/components sounds reasonable to me. Allowing other developers to use it could be amazing.

I really like how this is shaping up! Great work. Here's some design feedback:

1. First image needs to be centered better.

The webpage in the graphic feels like it's not quite centered. Even the blocks in the webpage don't look centered.

2. First two graphics should be equal width.

I think this may help visually if both graphics in the first two images are equal width within the blue container.

3. Should we capitalize certain things?

"Block Editor" or "Block Library" seem like proper nouns. For example, we capitalize Block Library in the sentence, but not in the heading of the third screen.

4. Second screen text addition

Should we mention that you can move the block toolbar to be fixed at the top of the screen for less visual distractions?

5. This icon can probably use some visual cleanup.

Also lets make the triangle white to match the popover graphic too. Right now it's grey.

I think these last few changes will dial it in beautifully.

Hey @noisysocks! This is looking great! 🎉

Visuals

Would it be possible to align the close button so it has the same space around like the previous and next/get-started buttons?

I also noticed that the hover state of the page control buttons looks a bit off. It looks like the right border is missing half a pixel (I'm on a retina display).

Accessibility

I was able to interact with the welcome guide using only my keyboard 👍

I also did a quick test with Voice Over and had a couple of issues:

The page control buttons could use an aria-label so it's communicated to assistive technology what they're for. I was expecting to hear something like "page 1 of 3".

I'm thinking these could be grouped on a ul so they're part of the same group. Following suggestions on how to markup content sliders from the Inclusive Components pattern library, it could be something like:

<ul aria-label="Welcome guide controls">
    <li><button aria-label="Page 1 of 3"></button></li>
    <li><button aria-label="Page 2 of 3"></button></li>
    <li><button aria-label="Page 3 of 3"></button></li>
</ul>

I don't think the images need an alt description, because the accompanying text does a good job of describing each page/topic. That being said, they should have an empty alt = "" so that they're ignored by AT.

Overall, this is looking great! Let me know what you think of my comments and suggestions.

@noisysocks where are you getting the images from? Let me know if you need help with Mark's suggestions on alignment and size.

Thanks @mapk and @enriquesanchez! I'll work through your suggestions.

@noisysocks where are you getting the images from? Let me know if you need help with Mark's suggestions on alignment and size.

I would absolutely love it if you could update the images for me! I got the SVGs from @jasmussen, who I think exported them from the 'Tips Iteration' project in the WordPress.org Figma team.

Hey @noisysocks! (I never get tired of your username 😃)

Here are the new SVGs with Mark's suggested changes:

illustrations.zip

Wait, I noticed the add block icon on 'illustration 3.svg` was still showing some weird artifacts.

Here's a cleaner version:
illustration 3_.svg.zip

1. First image needs to be centered better.
2. First two graphics should be equal width.
3. This icon can probably use some visual cleanup.

👍 I updated the images in d8cee82. Thanks for fixing those up @enriquesanchez!

3. Should we capitalize certain things?

👍 I capitalised 'Block Editor' and 'Block Library' in 745fdd4.

4. Second screen text addition

I'll defer to you all on this one. Let me know what you'd like the copy to be and I can update it.

Would it be possible to align the close button so it has the same space around like the previous and next/get-started buttons?

I updated the alignment in 47c2879, though I wonder if doing this makes the X button look too much like 'content' instead of 'chrome'? Let me know what you think.

The page control buttons could use an aria-label so it's communicated to assistive technology what they're for. I was expecting to hear something like "page 1 of 3".

👍 I updated the page controls to use the markup you suggested in 92e1773.

I don't think the images need an alt description, because the accompanying text does a good job of describing each page/topic. That being said, they should have an empty alt = "" so that they're ignored by AT.

The images already have an empty alt="" attribute.

Separately, it looks like #12632 would still be effected by this tips redesign. AFAICT, the close button here is dismissing all guides instead of just the current "guide".
Thanks for pointing me to #12632. I'll look into moving away from areTipsEnabled(). My preference is to make Guide a dumb component and leave it up to the plugin developer to decide when to show it.

Let's look at making the welcome guide use something other than areTipsEnabled in a separate PR. There are some details to consider there and I want us to have the opportunity to properly think it through. We also need to consider whether or not we want to maintain or deprecate the @wordpress/nux package. #12632 can track that work.

YES! Adding this to @wordpress/components sounds reasonable to me. Allowing other developers to use it could be amazing.

I've left Guide in the @wordpress/nux package for now because it requires isViewportMatch to determine whether or not to display the 'Get started' button inline with the content. Let's consider moving Guide to @wordpress/components in a follow-up PR—I've marked Guide as experimental for now so that we can do this.

The modal is not labelled. This is in part a problem with this modal, but should probably be corrected in the component: the Modal component allows the component to be misused.

We should enforce a label for the modal element with role=dialog within the e2e tests, because all modals must be labelled. Additionally, the modal component should enforce 'role="document"' on the content of all modal dialogs. This isn't strictly required on all modals, but the component can't know what type of content a modal will contain, this will give the best overall experience.

There are usability problems with having this modal open automatically on page load.

1. As it is (unlabeled), it's going to be confusing for some users.
2. It disrupts the flow for users who wish to use Gutenberg immediately.
3. Users who reflexively dismiss modals will not easily be able to get it back.

One possible way that this could be made available is to add a prominent button for users to launch the Welcome Modal if they are detected as new Gutenberg users. The modal, in that case, should have two cancel actions: one that simply closes the modal, and one that dismisses it persistently.

As a second issue, the method for assessing whether a user is "new" to Gutenberg is significantly flawed: the usage of local storage for this means that a user will be new on every device they use, on every browser they use, and on every new site they launch. Secondarily, because the detection appears to be based on the positive presence of 'modal dismissed' setting in local storage, it will essentially be impossible to permanently disable it; anytime the local storage is flushed it will come back. (See #15105)