Revise the approach to NUX tips

[kjellr]

Background

Tips were added via #3670 to provide brand new users with a walkthrough of the interface. On the surface, they are a good idea (education is always good!), but they have room for improvement.

I recently reviewed the set of usability testing videos posted to make.wordpress.org/design to get a sense of how users interact with tips today. A few things stood out:

1. Most users did not read the first tip. According to these tests (and backed up by informal discussions and observations I've had with users too), it appears that most users wanted to jump right in and edit.
2. Users do not advance to the next tip. Even those that did read the first tip did not click into the second tip in the series. Not one tester did. Are the 3rd-4th tips necessary? Are users missing important details there?
3. The current implementation of tips blocks essential UI. Many users ran into issues where the tips would block content. In some cases, users did not initially see the title block because the tip was blocking it from view. Similarly, when users acted on the tip instructions and opened the block library, the tip remained in place, blocking view of the library itself. 😩 There are a number of issues about this, including New User Experience (NUX) tips hide content relevant to New Users #15986.
4. The position of these tips is not ideal. Aside from the overlapping issues noted above, these floating tips don't always appear the way they're intended to. Especially on mobile. Related issues: NUX Tips: 2nd through 4th tips appear clipped off screen on mobile #16225, NUX DotTip Positioning #14923, NUX tips: Close button tooltip partially hidden on some tips #7562
5. The tips are somewhat of a dead end. Our current tips do not typically provide a link to more information if users want to learn more. Similarly, once you dismiss a tip, it's unclear how you can get it back (Though based on 1 and 2 above, I'm not sure users do want to get these tips back in the first place).

Suggestions

1. Move tips inline whenever possible. Rather than having tips in their own layer, let's try bringing them inline with the content. This would make them truly ignore-able for folks that want to do that, and prevent them from hiding important UI.

2. Eliminate stepped tips. Nobody appears to click on them anyway.

3. Consider starting with a single modal, asking whether or not users want guides in the first place. Not sure about this one, as it would clearly put a roadblock in front of all users. But on the other hand, some users clearly do want this sort of guidance — allowing users to choose whether they get tips or not may be a good idea.

Mockups

Here are a few early explorations into how this could work.

First, some mockups of an inline tip:

Here are examples of how one of these might look in other contexts:

And finally (not sure if we actually need this — more on that below, but) here's a quick example of what an initial modal might look like. The general idea is that if smoeone were to click on "Show me the blocks", Gutenberg would would open up the Block Library automatically, showing that first tip from the mockups above.

Prototypes

It helps to click around and try this out:

💻 Desktop Prototype

📱 Mobile Prototype

Considerations

A few things worth pointing out:

• Most importantly, this does not cover up any important content. 🎉 Because of that, these tips require no user interaction at all. If someone wants to ignore them, they can.
• Most of these tip mockups incorporate a link. Ideally most tips would include one. This would likely require more discussion around user-facing documentation, and ensuring we have corresponding pages for all the important bits we want to feature in tips.
• I'm not sure about which visual treatment for the tips I prefer — the dark looks nice and is reminiscent of our snackbars, but it also appears to be too prominent in some cases.
• I'm really torn about that introduction modal (and the subsequent auto-opening of the Block Library). In general, I think most users won't need it. But for first-time users I think it could be helpful.
• A clear downside to this is that some areas are too small for inline tips. Say you wanted to include a tip on a toolbar item for instance. This is possible today, but wouldn't be possible with these tips. Instead you'd have to include a tip somewhere near the item, and direct users to the icon in question via text or an icon within the tip.
• The inability to point to a specific thing is a little tough sometimes. This came up while working on the mobile prototype — if we opened the Block Library by default, these tips don't allow for a simple way to inform users how to open the Block Library themselves later on.
• Another downside is that you first have to click into an area to discover that a hint exists there. For instance: If you have the sidebar closed, you won't see any tips there until you open it up.

[jwold]

Part one:

I really like this suggestion to make tips inline. While tips have definite value, I've more often found myself trying to clear them out of the way when jumping into Gutenberg.

Consider starting with a single modal, asking whether or not users want guides in the first place. Not sure about this one,

Maybe there's another way we could do it.

When I start a new application and get a notification for tips, I usually say no. That's because I don't want my screen hijacked with 20 tips.

Now, if tips become inline, they're not jumping out at me.

If someone truly wants all tips to go away though, there's a few ways we could do that:

1. When a user presses the "X" on the first tip, ask if they want to remove all others
2. When a user presses the "X" on the first tip, tell them where they can turn on/off remaining tips
3. Inside of each tip have a "dismiss all" button (don't like this idea as much)

Part two:

I'm not sure about which visual treatment for the tips I prefer — the dark looks nice and is reminiscent of our snackbars, but it also appears to be too prominent in some cases.

Agreed that the dark does feel a little too prominent.

Thoughts on the four visual styles: https://d.pr/i/hByCv3

A. A bit too strong and starts to feel something that demands my attention
B. Almost feels like just a headline or info paragraph, which is awesome, but doesn't quite fit the pattern of WordPress so feels a bit out of place. If it was massaged a bit I I think it'd be my favorite.
C and D. I'm ok with them because they fit more of the pattern of WordPress, but.. I'm not a fan of them in general, maybe because I've stared at them too much over the years.

Part three:

One idea might be to try a notification a bit more up here: https://d.pr/i/DxaLel, similar to how I've been playing with a concept for Woo: https://d.pr/i/ByTU0P. Still a work in progress, but might provide inspiration.

Part four:

A clear downside to this is that some areas are too small for inline tips.

I might be oversimplifying this, but could we leave this up to the small (?) info areas, so a more on the user situation?

Another downside is that you first have to click into an area to discover that a hint exists there. For instance:

Ok, that's a valid point. Here's an idea, inspired by PUBG (a game on the iPad). When you have an area that you want to draw attention to, but it's too small to have an inline notice because it opens up something, you could do a small dot (need to make sure this is accessible), that stays persistent until the inline notification is viewed or removed (either depending on the context).

Here's a simple sketch:

[jasmussen]

Love your work here. I think the inline tips can be great as they are:

• contextual
• non-blocking, you never have that "go away" reaction
• can be ignored if you like

I also have a strong preference for this one:

— but will of course defer to the community sentiment :D

One note though, it doesn't feel like the icon needs to be larger than in its base 24x24 size. In being bigger, it feels like a different icon set because the stroke becomes thicker.

[fditrapani]

Thanks for sharing your thoughts and suggestions @kjellr! After a recent round of usability testing on WordPress.com, I noticed the exact same things you mentioned here. In addition to that, I also found people having a really hard time figuring Gutenberg out. One of the biggest issues we encountered was people changing images on the cover image block and also the regular image block.

Anyways, my biggest takeaway from the research is that we need to be doing more to educate people how Gutenberg works and also help them discover what it can do (Block discovery seemed to be challenging — you don't know what you don't know). I think the intro modal and inline tips will be very helpful with this.

[kjellr]

@jwold:

When a user presses the "X" on the first tip, ask if they want to remove all others

Yes! I definitely like this pattern, and have a mockup of this in the prototype actually:

One idea might be to try a notification a bit more up here: https://d.pr/i/DxaLel, similar to how I've been playing with a concept for Woo: https://d.pr/i/ByTU0P. Still a work in progress, but might provide inspiration.

Ah, cool. Yeah that placement seems more natural than what I have in the mockup above. 👍

I might be oversimplifying this, but could we leave this up to the small (?) info areas, so a more on the user situation?

Not sure I follow there — can you rephrase that?

Ok, that's a valid point. Here's an idea, inspired by PUBG (a game on the iPad). When you have an area that you want to draw attention to, but it's too small to have an inline notice because it opens up something, you could do a small dot (need to make sure this is accessible), that stays persistent until the inline notification is viewed or removed (either depending on the context).

I considered this, but I do worry that pulsing blue shapes with no clear "close" action will end up being really annoying to users. It may be okay if the user has specifically said they want tips, but I envision people being annoyed at having "notifications" like that popping up across the interface.

---

@jasmussen:

I also have a strong preference for this one:

I share the concern that @jwold has — that it blends in with the UI just a little too much.

After another day of reflection, I think it may make sense to follow the default WP notification styles for now — these are essentially little alerts within the interface, so I'm not sure it makes sense to create a whole new pattern for them:

One note though, it doesn't feel like the icon needs to be larger than in its base 24x24 size. In being bigger, it feels like a different icon set because the stroke becomes thicker.

Good point. I heard similar feedback from @shaunandrews as well. I tried that size originally, but I found that it seemed "floaty" when there were only two lines of text:

Centering it wasn't much better, so I tried bumping it up to the height of two lines, and that felt about right to me. I think the 24px could grow on me though. Even just looking at it again now, I'm not really concerned about it. (That said, if we use the standard WP alert style, I'm not sure we need an icon here at all).

---

@shaunandrews raised another great point about these — our documentation should definitely suggest a max word count — the four-line examples in my comps seem a bit too big. Nobody wants to read a tip that long. 😄

One related idea: It might be cool if each tip were a short sentence or so, along with a link that opened additional help content in a modal or something, so that users didn't have to completely exit the page if they need more help.

[jwold]

@kjellr thanks for the followup!

I might be oversimplifying this, but could we leave this up to the small (?) info areas, so a more on the user situation?

I've rethought that statement and realize it's not as relevant as I thought. I was talking about making use of these in Gutenberg where relevant: https://d.pr/i/tIB8Jz. So offering an info tip if people ask for it via those small icons.

I considered this, but I do worry that pulsing blue shapes with no clear "close" action will end up being really annoying to users. It may be okay if the user has specifically said they want tips, but I envision people being annoyed at having "notifications" like that popping up across the interface.

Another point to agree with what you said is notifications aren't really a good thing to use for info tips.

[shaunandrews]

When a user presses the "X" on the first tip, ask if they want to remove all others
Yes! I definitely like this pattern, and have a mockup of this in the prototype actually:

This is cool. But I worry about the consistency of this UI across various sized inline tips. Perhaps this should be an alert/confirmation modal?

[jasmussen]

After another day of reflection, I think it may make sense to follow the default WP notification styles for now — these are essentially little alerts within the interface, so I'm not sure it makes sense to create a whole new pattern for them:

Great observation. It helped me understand why I had a preference for the white notice: it's an existing design. The dark version did not have precedence, so it was new UI. New UI can totally be appropriate at times, but if there is an existing pattern we can use that's nearly always better. For that reason, the default Banner notification style fits the bill.

Centering it wasn't much better, so I tried bumping it up to the height of two lines, and that felt about right to me. I think the 24px could grow on me though. Even just looking at it again now, I'm not really concerned about it. (That said, if we use the standard WP alert style, I'm not sure we need an icon here at all).

It kind of feels like we might want to have some guidelines for how to use icons — there really aren't any rules. Big and small icons are used here and there. In this case at the moment the 24px icon (so that the stroke widths match) is definitely in a personal preference thing for me, which means it's feedback that's okay to dismiss :D

Go forth and conquer!

[karmatosed]

Just a little note of personal preference (so it can be framed that way), the dark is way easier for me to read so was refreshing to see on the interface. I found it more soothing for the Tips to be in the scheme. I say this though as someone that lives and embraces "dark mode all the things", so perhaps that is why. For my visual preferences, it just makes everything easier to read.

[kjellr]

Thanks everyone for the feedback! I'm back with some revised mockups.

First of all, the revised style for the inline tips themselves: As discussed above, the default banner notification style seems to make a lot of sense here: These are inline alerts, so there's no need to reinvent the wheel when it comes to the styles. If they're inline alerts, they should be styled like inline alerts. I don't believe these banners allow for an icon currently, but I could see us potentially adding one in to help these "tips" alerts seem to be a specific type of alert:

I'm interested in thoughts on that. For now, I've left the icon out of the rest of the comps in this comment.

Here's how that looks in a few different contexts:

I've also updated prototypes with these new treatments:

💻 Desktop Prototype

📱 Mobile Prototype

These include a few other adjustments, as per the comments above:

• Copy has been trimmed, so all tips are 2-3 lines
• Disable tips confirmation is now an alert, instead of being inline
• The in-placeholder tip example has been moved up to the top, similar to the explorations that @jwold shared above.

---

If folks seem on board with this approach, I suggest we start taking this to PR to give this a try in context. The steps to do this would be:

1. Turn off/depreciate the existing tips component.
2. Replace or remove the four existing dotTips in Gutenberg:

Step 1: "Welcome to the wonderful world of blocks! ..."

This can be transitioned to the inline Block Library example in the comps above. This should be visible the first time the Block Library is opened, and remain there until it's closed. For now, the "Read more" link should point to the "Blocks" documentation on wordpress.org/support.

gutenberg/packages/edit-post/src/components/header/header-toolbar/index.js

Lines 35 to 37 in c5f95a2

	<DotTip tipId="core/editor.inserter">
	{ __( 'Welcome to the wonderful world of blocks! Click the “+” (“Add block”) button to add a new block. There are blocks available for all kinds of content: you can insert text, headings, images, lists, and lots more!' ) }
	</DotTip>

Step 2: "You’ll find more settings for your page and blocks in the sidebar..."

I'm not 100% sure this is necessary, but for now we might as well replace it with the block sidebar message in the comps above. This will be visible the first time the block sidebar is visible. The "Read more" link should point to the "Configuring a Block" section of the Gutenberg documentation on wordpress.org/support.

gutenberg/packages/edit-post/src/components/header/index.js

Lines 75 to 77 in c5f95a2

	<DotTip tipId="core/editor.settings">
	{ __( 'You’ll find more settings for your page and blocks in the sidebar. Click the cog icon to toggle the sidebar open and closed.' ) }
	</DotTip>

Step 3: "Click “Preview” to load a preview of this page..."

I think we can lose this one for now.

gutenberg/packages/editor/src/components/post-preview-button/index.js

Lines 194 to 196 in bb8deba

	<DotTip tipId="core/editor.preview">
	{ __( 'Click “Preview” to load a preview of this page, so you can make sure you’re happy with your blocks.' ) }
	</DotTip>

Step 4: "Finished writing? That’s great, let’s get this published right now..."

Similarly, I think we can try removing this one for now. It may be helpful to put some information in the Publish sidebar, but i know there's activity on that in another ticket.

gutenberg/packages/editor/src/components/post-publish-button/index.js

Lines 120 to 122 in b62e0f5

	<DotTip tipId="core/editor.publish">
	{ __( 'Finished writing? That’s great, let’s get this published right now. Just click “Publish” and you’re good to go.' ) }
	</DotTip>

---

Still left to do:

1. Decide whether or not we need that initial welcome modal.
2. If we keep it, we need to determine what the modal says, and what the accompanying graphic is (if any).
3. Finalize decisions around the visuals for these tips (though we can also iterate in the context of a PR).

Looking forward to hearing your thoughts, comments, and concerns!

[kjellr]

Another separate-but-related idea:

These tips would be extra useful if we were able to include some sort of graphic or video too. For instance, in the Block Library, maybe these could be accompanied by a brief video introduction and walkthrough for inserting a block:

Clicking the thumbnail would open that content up in a modal:

🖥 Prototype

Of course, we'd need that video content to be created + updated. But I do think it would be incredibly useful for folks.

[jwold]

These tips would be extra useful if we were able to include some sort of graphic or video too.

+10000 to this! 😀

[jasmussen]

You're rockin' it, Kjell. Back when freelancing I would record such videos myself, to help my clients understand how to use this or that customized feature. Can these inline tips be built in such a way that any block author can add the tips, and perhaps add those videos directly there? My past self would have been all over that.

Let me know if you'd like me to create a separate ticket for that idea, if it's worth it, don't want to take focus away from this otherwise wonderful thread.

[kjellr]

Thanks, @jasmussen! I've broken that out in to a separate issue to keep us on track here: #16463

I've also opened an issue to document another exploration for NUX. I don't think most of it has legs, but I figured it's worth opening for discussion at least: #16464

[noisysocks]

👋 happy to work on this once it's ready for dev. I replaced #3670 with this issue on the Phase 2 board.

[kjellr]

Alright, here's what I think:

@noisysocks, I think we're ready to get going on the two items noted in #16315 (comment):

1. Turn off/depreciate the existing tips component.
2. Replace or remove the four existing dotTips in Gutenberg

... using the recommendations for each of the 4 existing tips that's in place there. The only outstanding question is the intro modal — I'm going to get some sample content ready for that soon, but I think we may actually want to build that out in a separate PR anyway.

Does that sound about right to folks? The two tips we'll start with are the ones that tie into key success actions that we hope the user takes:

1. Finding a block (in the Block Library)
2. Modifying a block (in the Block sidebar)

We can direct the user to those actions specifically once we get the modal up and running, and we can test + add more tips as needed once these first ones are in place.

[karmatosed]

Does that sound about right to folks?

Yes this sounds great! I think using this to then test makes sense. Are you thinking to test the PR or have this tested in plugin release? I can see value in testing in plugin.

[noisysocks]

The only outstanding question is the intro modal — I'm going to get some sample content ready for that soon, but I think we may actually want to build that out in a separate PR anyway.

Yep, I see three PRs here:

1. Replace existing tips with two inline notices.
2. Add an intro modal to the editor, and make the inserter appear when 'Show me the blocks' is clicked so that there's a natural "walkthrough".
3. Add video content to the inline notices.

[kjellr]

Excellent, thanks all. Let's get going on that first one to start with. 👏

[kjellr]

I took a stab this morning at working out some new comps for the intro modal segment of this work. For the most simple state, I'm thinking something like this:

(Here's a mobile version, too)

The general idea here is that users could click "Open the Block Library", to exit this modal and open up the Block Library. That would set them up with the first tip noted above (If we use this modal, we may want to revise that tip's copy since it it replicates what's in this modal). If the user says no thanks, the modal just closes.

A few notes on this mockup:

• This started with the standard Modal component, but I removed the divider line from the header, as well as the heading in the upper left. Those felt unnecessary in this case, but I'm interested to hear if anyone has any objections (especially from a code/components side). Here's how it looks with those elements added in again.
• I like bringing the blue background there into the images — I think that really helps brighten things up.
• Each one of these graphics can be easily served as SVGs, so there's no need to host the images anywhere.
• Theoretically, we could also animate those SVGs someday if we wanted to.

---

I also mocked up an alternate version of this modal that includes more steps:

These steps center around 3 key bits of knowledge about the interface. The general idea is that if they know those 3 tips, they should have a solid high-level overview of what's going on.

1. Everything is a block.
2. Blocks have their own controls (in the toolbar, as well as the sidebar.)
3. Blocks can be found in the Block Library.

Here are prototypes of how that would work:

🖥 Desktop Prototype

📱 Mobile Prototype

I do like these extra two steps, in that they provide a bit more information. But my gut tells me that folks are liable to just skip this anyway, so I'm not sure how useful it is compared to the one above. I'm curious to hear others' thoughts.

[kjellr]

@mtias: I'm curious if you think we should continue with the intro modal portion of this ticket, as mocked up above. 

I think it's still generally compatible with the direction in #16592. The buttons would direct first-time users to the Block Library to get started, which seems especially useful with the new tips there.

[mtias]

@kjellr I think there is still value in the more walkthrough portion of this, but I'd like to prioritize all the others we discussed first as they are more connected with permanent UI.

[kjellr]

Now that #16813 has been merged in, I think we should try re-assessing this issue. The current tips implementation is still very buggy and broken (#16225, #14923, #7562), so some change is definitely needed. I think there's actually a relatively simple way to move forward here:

Let's disable our current implementation of tips entirely, and replace it with just the single three-step modal depicted above.

(Yes, that means not using the inline NUX tips that were the initial drive behind this whole GitHub ticket, but hear me out... 😄 )

The new inserter help panel already covers our first "This is where you find blocks" tip, so there's no reason to include that one. As noted above, nobody ever tended to click through to the other tips anyway, so I don't think it's necessarily worth including those either. I think we might as well take all those NUX tips out and start fresh.

The modal is straightforward, is only available once, and is easily dismissible. It's a simple, self-contained entrypoint that will work nicely on mobile and on desktop. Once users move beyond that first-time experience, they'll be supported by the inline help that's better handled by other open issues (#17091, #16315, #16594, etc.).

If we were to do this, I'd simplify the modal down a little bit, so that it results in just a "Get started" button at the end, and drops you off onto your empty page:

🖥 Desktop Prototype

📱 Mobile Prototype

This seems like a simple, self-contained replacement for the current broken NUX Tips implementation. I'd love to hear what others think of the idea.

[jwold]

Let's disable our current implementation of tips entirely, and replace it with just the single three-step modal depicted above.

So we'd remove any other tips within Gutenberg and display the modal you've suggested? I like it! It's clean, dismissible, simple, and useful. +1 from me. :)

[noisysocks]

Makes sense to me!

I think it's worth exploring using inline tips for more advanced parts of the app e.g. reusable blocks, but we can focus on that at a later date.

I've closed out #16582 and unassigned myself.

[talldan]

@kjellr I've removed some of the labels as they seemed out of date. That includes Needs Design Feedback, but I wasn't 100% sure if you still needed feedback on this. Feel free to add it back on!

[kjellr]

Thanks, @talldan It sounds like the intro modal described above is ready to go to PR, so I'll add Needs Dev too.

[kjellr]

Just a note: I've updated the issue title to take into consideration the new direction here: #16315 (comment).

[noisysocks]

I'm picking this one back up again.