Blocks that link: Provide a split label/URL control and placeholder state

[jasmussen]

What problem does this address?

Splitting this one out from, and basing the design on #28440.

When you insert a link block such as a Menu Item or a Button (to a lesser extent, a Social Link), for the block to be functional it needs to have both a URL and a label configured. At the moment, this happens in a single link dialog interface.

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 use the arrow keys to highlight an existing page, the input field will become the label, and the selected item will become the URL.

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:

In other words, the same input field is used to provide both a label and a link destination, but it's not consistent which one you get. This is causing a number of headaches:

• An "add link" prompt, when in fact it's the label that's missing: Navigation Block: Editing the label of block causes Add Link prompt to appear incorrectly #30163
• We're not sure when/how to HTML encode entities and when not to: Navigation Block: Creating a draft page with “&” results in HTML Entities #30111
• Mostly, and this was a key reason for adding the menu item placeholder (Navigation: Reconsider placeholder state for the Link block #28440) in the first place, a button with a label but no link, or link but no label, is quite useless.

What is your proposed solution?

Keep button blocks, menu items, social links in their placeholder states until both a URL and a link has been added, and split the link dialog to enable it.

These designs are courtesy of @shaunandrews from #28440 (comment):

Adding a Link

Empty.Link.i1.mp4

Adding a Page Link

Empty.Page.Link.i2.mp4

See also:

#29505
#30116

[jasmussen]

Here are some fresher mockups for how a split URL/Label dialog could look.

[getdave]

@jasmussen I found a PR I worked on which tackled this very concept

#19413

[jasmussen]

I'd be happy to pair with you on a resurrection of this one!

[getdave]

💯 lets do it!

[jasmussen]

Per conversation in #33849 (comment), I explored a few additional designs for split label/URL dialogs. The following remains a work in progress, there are some details that need to be hashed out.

1. For page links, show an explicit "select page" button, which slides the contents sideways to show the list of pages as a screen 2 choice:

This is meant to be a future exploration that will be dependant on components from the global styles work to land first.

2. Text, link and "recently updated" list of results:

This is mostly a small refresh of the work in progress in #33849. It feels a bit heavy.

3. A minimal version that only shows search results when you start typing:

Things we likely need to discuss in order to move forward on one of these is:

• What is the value of keeping an identical URL dialog across pages, custom links? As a reminder, this mockup shows how the dialog could adapt to its context.
• How valuable are the "recently updated" suggestions? At the moment they aren't contextual to the block type, and I find they don't change that often and therefore have somewhat dubious value.

[getdave]

Good to see this evolving. I'm keen to progress #33849 so please do let me know if/when I can do that.

1. For page links, show an explicit "select page" button, which slides the contents sideways to show the list of pages as a screen 2 choice:

This is great if you don't remember the page name but less optimal if you do (when search really shines). Have you seen @javierarce's exploration with bulk adding of links?

Text, link and "recently updated" list of results:

This is the simplest "next step" towards improving the link editing UI across the editor. We can always ditch the "Recently updated" or at least toggle the default prop so it's off by default.

What is the value of keeping an identical URL dialog across pages, custom links?

I'd say simplicity. Once you've learnt one UI you've learnt it. Whilst I think we as regular contributors will adapt quickly to varying UIs based on context ,I'm not so sure users will feel the same. See for example the UX problems with the different variations in the Nav Link block where users now need to understand the difference between a Post and a Page in order to add a link. We should be able to construct a UI that does the 80% of cases and provide other mechanics to ease the UX for those who require the 20%.

How valuable are the "recently updated" suggestions? At the moment they aren't contextual to the block type, and I find they don't change that often and therefore have somewhat dubious value.

I doubt they are that useful. They were added when I originally created the <LinkControl> component but there's been a lot of water under the bridge since then. Honestly I suspect most folk would just search and ignore those items.

[jasmussen]

This is great if you don't remember the page name but less optimal if you do (when search really shines). Have you seen @javierarce's exploration with bulk adding of links?

Very nice work. I'd prefer to avoid tabs here, and keep the dropdown fairly compressed if we can. Just as an experiment:

I'd say simplicity. Once you've learnt one UI you've learnt it. Whilst I think we as regular contributors will adapt quickly to varying UIs based on context ,I'm not so sure users will feel the same. See for example the UX problems with the different variations in the Nav Link block where users now need to understand the difference between a Post and a Page in order to add a link. We should be able to construct a UI that does the 80% of cases and provide other mechanics to ease the UX for those who require the 20%.

Good argument. However I do feel like the fact that everything just becomes generic URLs might do a disservice to the taxonomies we know of, like tags, categories, pages, etc., as well as the leaner way we can potentially display those. @shaunandrews since you basically originated the design ideas in #28440, do you have any thoughts to add?

I doubt they are that useful. They were added when I originally created the component but there's been a lot of water under the bridge since then. Honestly I suspect most folk would just search and ignore those items.

👍 👍

[getdave]

the fact that everything just becomes generic URLs might do a disservice to the taxonomies we know of

Let's say for arguments sake we were able to retain the "taxonomy" part once the link is added (ie: we don't just use the URL) would that help?

I also dislike this behaviour although it's different in Nav Block vs in RichText.

[jasmussen]

I think we may be arguing in favor of the same thing. Basically that most of the behavior of the box is identical across rich text and any block that might link to destinations, but just that the destination interface might be optimized for each type. Sort of like this somewhat simplified version:

[jasmussen]

An important conversation about a more basic menu building experience is happening in #34041. Mockups to address that show a simpler URL picker as part of that flow:

While putting those together, it became clear that when you link to pages on your site, choosing the page and adopting its title is the primary action. However the split title/link dialog might still be useful after the fact:

This dialog already exists — you get it when you press the Link button on a menu item. But the above overhauls it slightly to include the split title/link interface. By showing the ability to edit the label in context of unlinking the item, if paired with #33091, we can enable pattern designers to create opinionated menu patterns that come with predefined label suggestions, but which don't link anywhere.

Consider that patterns already exist which output Buttons that have labels:

"Learn more" in the above screenshot doesn't link anywhere, but it's not easy to notice. The navigation block implements a "squiggly underline" pattern to indicate that the link is missing. In that vein, the squiggly line paired with a unified split dialog which opened on links or buttons that have labels but don't link anywhere, we would be embracing the ability to create such patterns, and hopefully lower the likelyhood of users accidentally publishing dead links.

[getdave]

@jasmussen Thanks for the update. Looking good ❤️

Can I confirm you're proposing redoing the design of the Link UI across Gutenberg to use this new layout (which also happens to utilise split text/URL)?

If so I'd be in favour of this. We should probably account for "Rich URL Previews" in the designs however.

In terms of the custom "Page" dropdown version - do you see this a unique to the Nav block? <LinkControl> has some ability to be extended to accommodate different designs of suggestions, but I wonder whether if we're going to start stretching this component we ought to revisit it at a more fundamental level? It's starting to grow fairly complex, partially due to the reliance on <URLInput>, and I wonder whether we should consider re-writing before we add yet more complexity to the existing component.

That's longer term though - in terms of the new design you propose we should proceed.

[jasmussen]

Can I confirm you're proposing redoing the design of the Link UI across Gutenberg to use this new layout (which also happens to utilise split text/URL)?

Yes, from exploring the mockups further, that seems to be the right interface for the split dialog.

If so I'd be in favour of this. We should probably account for "Rich URL Previews" in the designs however.

Definitely, and in fact it might be worth lowering the priority of this one. It seems a good enhancement, but by virtue of being secondary, it seems less urgent.

In terms of the custom "Page" dropdown version - do you see this a unique to the Nav block? has some ability to be extended to accommodate different designs of suggestions, but I wonder whether if we're going to start stretching this component we ought to revisit it at a more fundamental level? It's starting to grow fairly complex, partially due to the reliance on , and I wonder whether we should consider re-writing before we add yet more complexity to the existing component.

The proposal for the lighter navigation in #34041 is to add a feature to the inserter where if the parent block has a default block defined, the plus inserts that, and adds a "Transform" option to the bottom of the URL dialog. At the moment this feature is definitely inspired by the navigation block, but I could see it making sense in other container blocks as well.

The second half of the equation is whether to show a generic "Recently updated" list of items in the URL dialog across all links, or whether to tailor it to each item type. I think the answer here depends on how much effort we want to put into it. At a minimum I think there's notable value in having a page selector in addition to the default "recent items" filter. But the idea is that if you insert a category link, a suggestion of recent posts published isn't that useful. Here's a mockup just putting the puzzle pieces on the table:

We still need to piece them together to form a compelling picture. But the idea is to filter the labels and queries based on the block type inserted.