You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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?
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.
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
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.
Eliminate stepped tips. Nobody appears to click on them anyway.
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.
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.
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:
Suggestions
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.
Eliminate stepped tips. Nobody appears to click on them anyway.
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: