Navigation: Reconsider placeholder state for the Link block

[shaunandrews]

When you add a new Link block within the Navigation block, the Link UI appears. However, if you click anywhere or generally move focus away, the Link UI disappears and its difficult to determine how to complete setting up the Link block. This leads to empty Link blocks with placeholder "Add link" text that doesn't do anything.

Empty.Links.mp4

I think it could be helpful to improve the Link block's placeholder state. For example, if you unselect a newly added Link block we could show a button to reopen the Link UI and add a URL:

Link.Placeholder.mp4

The experience for adding a Page or Post link could be adapted as well:

Page.Placeholder.mp4

[jasmussen]

I'd love to work with you on this! The duelling popovers is just boxes in boxes. Additionally, the combination of a URL and URL label means it's hard to know what you're editing and when.

Your instinct here, to provide a setup state for the link button, I think is a great instinct. But I think we can both expand this to other blocks that are "button containers", like Social Links and Buttons. In turn, this can help inform what happens when you click the empty state.

Basically, when the block is "unconfigured", it has the setup state button that simply invokes the URL & Label popover, just as you show. Or in the case of social links, just the URL. This setup state could be a skeleton indicator when the container is unselected, and a label when selected, that both indicates that it's incomplete, and lets the setup state match the parent context (such as Buttons or Social Links). This would let us have a pretty clear shift between "clearly setup state" and when it's selected, which could just be a preview with placeholder text.

Additional thought: once a button is configured, I wonder: should the popover appear every time you select the block? Honestly editing the menu item label isn't that good of an experience inline. If we did this, we could remove the link button from the toolbar. Alternately, we should at the very least make sure the link button shows as "toggled" when a URL is configured vs. when it isn't.

This is great, Shaun, excellent work.

[shaunandrews]

I wonder: should the popover appear every time you select the block?

I don't think so, no. Otherwise it can quickly become overwhelming having both a block toolbar and a URL popover. Also, considering submenus along with the vertical layout variation it could become difficult to select/navigate between blocks as there'd be an abundance of floating boxes to deal with.

[shaunandrews]

Spent some more time on this earlier today and came up with the following:

Adding a Link

Empty.Link.i1.mp4

--

Adding a Page Link

Empty.Page.Link.i2.mp4

[jasmussen]

I'm a big fan of your work here, Shaun. I believe that with this ticket you will have solved the biggest headache that exists for the navigation block, and that pieces will start to fall in place shortly after this. And not only that, you will have found an interface that will benefit also the Social Links block, as well as the Buttons blocks, who both suffer from this same problem, even if to a lesser extent.

One tiny thing. Showing the container and selected block border we can definitely revisit. Even now, the "selected state" is currently a 1px solid border in the site editor, which allows that same border to grow thicker and blue when focused:

Although we can look at using a gray background color as "highlight", I worry that will fail in some context, such as when the theme styles menu items to have background colors on their own. Or as with the social links block, where the highlight is largely obscured by the block itself:

For that reason, and because everything else about this effort is so potent, I'd keep the selected border the same as it is in the site editor for now, and then we can look at a different highlight state separately. Make sense? I.e. something like this instead:

What do you think?

[talldan]

I like it, I think it could potentially help solve a few separate issues. At the same time I'm a bit nervous about adding another link UI. There's some tech debt built up around previous link interfaces, and also previous design-led efforts to unify the interfaces. Still worth trying given the positive feedback so far, devs will have to be careful about how it's implemented

I think there are some edge cases to work out:

• How would the Text input handle formatted text? Currently the link text can be formatted bold, italic etc when edited directly. I wonder if we could try a RichText masquerading as an input in the form? Would that be weird?
• A bit like shown in the Empty Link video above, a user could dismiss the popover when unfilled using the escape key. How would it be reopened with only the keyboard in that situation? I wonder if it'd be ok to have the 'Add Link...' placeholder act as a toggle button that opens the popover ... the main part I'd be concerned about is whether it's unusual to have that button move to the toolbar after submitting the form and replaced with editable text.

[jasmussen]

At the same time I'm a bit nervous about adding another link UI.

I definitely think there's an opportunity to reduce and combine some of these. From the work that's been done already, there have been pros and cons.

That said, the pieces that are important to that particular flow are:

• You can click the empty menu item, but not edit text there at all. It's only a block, which opens the link UI when selected.
• Because you can't edit text directly in the placeholder itself, you have to be able to edit the text in the block UI that appears.

In that vein, I think of that link control more like "block UI" than a new popover interface. I could compare it to the caption field that pops out at the bottom when you select an image. I would also expect this same UI to be reused for both Buttons and Social Links blocks.

How would the Text input handle formatted text?

I don't think it needs to. I think it's okay for that to be the next step in the flow. I.e.

1. Insert a Link block in the navigation block, and you get an empty menu item with the URL UI shown
2. Press tab to focus the Text input field, add a title
3. Press tab to focus the URL input field, att a URL
4. Once both are filled out, press tab to set focus on "Save URL" and press Enter

In that flow you've created a menu item, and you can now click the text directly in the menu item to edit it, bold or italicize it. Make sense?

A bit like shown in the Empty Link video above, a user could dismiss the popover when unfilled using the escape key.

Depends if it's actualy a popover or not. If it's just UI that appears when the button is selected, like the caption field on an image, Escape would just select the block.

But if it is best implemented as a popover, then precedence for the behavior could potentially be found in the default block appender that appears on a new post:

The "Start writing..." prompt here is effectively a button, which when clicked adds an empty Paragraph block with focus.

[talldan]

In that flow you've created a menu item, and you can now click the text directly in the menu item to edit it, bold or italicize it. Make sense?

Yep, though I did notice in @shaunandrews' mockup there's an edit button in the toolbar, which I think shows the UI again. I suppose in this case you could make the Text non-editable.

[jasmussen]

Related: #24099

[georgeh]

I'm going to take a stab at implementing this. Once I get it working I'll see what we can do about integrating it with the LinkControl component.

[jasmussen]

@georgeh even before you get anything working, I would super duper love to be involved. I'm so excited about Shaun's idea here. Ping me whenever and for whatever reason! Thank you.

[georgeh]

It sounds like this will solve 3 problems:

1. When you click off the Link block without a URL, it's not obvious that the URL is missing, so we highlight it in the Nav
2. Once you click off the Link block, the LinkControl dialog doesn't display again, forcing people to hunt through the menu for the right button (assuming they know it's there). By always showing the dialog, it's easy to edit the URL every time
3. There's no placeholder text when it's empty

Can we solve 2 by popping the existing LinkControl on the block every time it has focus? Or at least when it has focus and the URL is not configured? And 1 can be solved without changing the way links are inserted.

Also, is it intentional not to use LinkControl in the Popover? I think that people will be used to seeing some of the UI bits for entering a URL normally and we'd want the experience to be consistent.

[gwwar]

I was pairing with @georgeh today, and I had two other questions for folks:

1. Does it make sense to continue using RichText? Or for navigation links, is it more of a one-click area/placeholder that brings back the popover or linkcontrol in focus
2. While investigating __experimentalInputControl, it looks like it uses css-in-js via emotion. I'm curious if this is a new pattern for gutenberg components. Default css specificity was pretty high, something like (0,0,5)

[jasmussen]

Can we solve 2 by popping the existing LinkControl on the block every time it has focus? Or at least when it has focus and the URL is not configured?

Yes, I think that's something to consider. After all, until a link is configured, the menu item is virtually useless, and that uselessness is what drives the ultimate need for a more opinionated setup state.

Also, is it intentional not to use LinkControl in the Popover? I think that people will be used to seeing some of the UI bits for entering a URL normally and we'd want the experience to be consistent.

I think there can be value in the reduction of the link control. However it might be worth just using the stock linkcontrol for the first draft of the PR, and then we can always upgrade with a followup. Sound good?

[jasmussen]

Does it make sense to continue using RichText? Or for navigation links, is it more of a one-click area/placeholder that brings back the popover or linkcontrol in focus

It is my impression that there's still value in allowing you to bold or italic text inside the menu item label. However if it simplified things, I wouldn't mind if that rich text value only became available the menu item was successfully configured, i.e. that it wasn't available in the setup state.

While investigating __experimentalInputControl, it looks like it uses css-in-js via emotion. I'm curious if this is a new pattern for gutenberg components. Default css specificity was pretty high, something like (0,0,5)

I think that @ItsJonQ has been doing some CSS in JS work, so he could be the person to ask. #27331 is also valuable to dive into, in that light.

[ItsJonQ]

While investigating __experimentalInputControl, it looks like it uses css-in-js via emotion. I'm curious if this is a new pattern for gutenberg components. Default css specificity was pretty high, something like (0,0,5)

@gwwar Haiii!!! The __experimentalInputControl does have somewhat highish specificity. However, the new components crafted with the new Component System effort will be substantially higher. This is intentional as the system is designed to ensure that UI can render reliably into various environments, regardless of existing CSS rules.

This setup was also designed to encourage a systemic way to making UI adjustments.

Ideally, any UI adjustments can be accommodated through component props (e.g. size) or by using the component with other components (e.g. layout related changes).

Custom CSS can be done using the Style System. How these styles are "bound" to the UI is much more intentional and often clearer to trace and control.

Hopefully this will reduce the amount of awkward CSS rules scattered throughout the codebase (which is the problem now).

[gwwar]

Gotcha @ItsJonQ! So it should be safe to use here? Do we happen to have an example PR or blog post of how we'd like to compose ui styles? I'm mostly curious of the pattern for different use cases

[ItsJonQ]

So it should be safe to use here?
@gwwar I believe so. However, if you're running into issues, you can fallback into the stable TextControl.

Do we happen to have an example PR or blog post of how we'd like to compose ui styles?

I don't have one that walks through the exact process. I wrote one a while back describing the higher level mechanics of the Style System:

https://g2components.wordpress.com/2020/08/31/creating-a-style-system/

The new Component System UI won't be available for a while, as we're still working on the initial integration into Gutenberg. We've learned a lot since starting integration back in Nov 2020.

I'm planning on writing a more formal introduction of the project very soon (as in, my plans are to start writing today).

Afterwards, I'll provide info as more of the system becomes available within Gutenberg.

Hope this helps!

[jasmussen]

Thank you Shaun and George! 👌

[shaunandrews]

🎉

[jasmussen]

@shaunandrews @annezazu I'd like to either reopen this one, or create a new followup ticket, to revisit this bit:

Specifically the idea that the menu item remains in a placeholder state until you have filled out both the URL, and the label.

I was looking at #30111, and it became clear that the navigation block link box accepts anything you give it.

If you type arbitrary text, you are meant to be searching for a page or post that you can choose from the dropdown, or create a draft with that title. For example if you type "WordPress", if you just press Enter, you will create a menu item labelled "WordPress" which links to WordPress:

But if you briefly use the arrow keys to touch a linked page, it will link to the item you hovered, and give it the title you used:

If you just paste a hyperlink and press Enter, you get a link item that correctly links to that hyperlink, and with a label that's an "educated guess" based on the URL, but still not a good label:

This behavior is at best confusing.

To an extent, and this I believe is at the core of Shaun's design here: we shouldn't consider a navigation item to be complete and useful until it has both a URL and a label.

I have some thoughts on how we might proceed, but would be curious about your thoughts first.

[annezazu]

we shouldn't consider a navigation item to be complete and useful until it has both a URL and a label.

I completely agree with you. This "placeholder problem" is that something that has come up repeatedly in FSE Outreach Testing and the chances of adding incomplete menu items (URL + label) is still quite high right now. I like the idea of having both be required.

Tied to this, there are also problems like this with the current experience where if one adds a link in but then wants to change the label, it's hard to know if after changing the label the link "stuck". Here's a video for context:

navigation.block.mov

[talldan]

For example if you type "WordPress", if you just press Enter, you will create a menu item labelled "WordPress" which links to WordPress

That could be a bug. I thought only named items (posts, pages) from the suggestions should pre-fill the label. Good to try a different solution that makes the process clearer though.

[jasmussen]

Opened #30170 as a followup, focused just on the updated link dialog.