Link UI (<LinkControl>) Overview Issue

[getdave]

This issue captures the current priorities for the Link UI which we are aiming to include in a (near) future release of WordPress.

There's also a longer backlog used to more exhaustively track open issues, bugs, and pending tasks at #35073.

⚠️ This is not the place to track bugs. Please use the Tracking Issue.

Key Problems

Design/Visual/UX

• Different link types for different contexts.
• Users want more controls available including:
  • "No follow"
  • CSS classes
  • ...extension points for 3rd party developers
• UX confusion re: committing changes to settings/link text.
• No way to close the Link UI - critical for a11y.
• Search results are limited unintuative.

Technical

• Link relationships are not preserved for WP entity links
  • Link UI does not preserve link relationships for Post (entity) links #32282
  • NavigationLink: make the URL dynamic for links to Posts #18345
• Developers want extension points for adding more controls.
• Component implemented (consumed) differently across Gutenberg components and blocks. There should be a standard, unified implementation.
• Toggling settings resets state of link.
• Determine user intent for links and URL validation.
• Remove dependency on URLInput and migrate to standalone implementation.
• Ability to customise the search suggestions criteria and results.

Accessibility

See this list.

Relevant Resources

• Link Control tracking issue.
• Recent revision of Link Control UX and Design to include settings drawer and Apply/Cancel buttons.
• Related Issue with new Design for creating Navigation links using the Link UI.
• Historical Issue with Joen's mockups of suggestions for evolving the Link UI.
• Historical Issue with design revisions to Link UI.

[SaxonF]

Attached some designs below which attempt to consolidate this and this.

Navigation

navigation.mp4

Inline

inline.mp4

Media

media.mp4

Figma prototype

[jasmussen]

Really nice work Saxon, I dig it.

Do we actually need to show the permalink on the main link? To me the magic of a page is that it'll always link to the Page, no matter if its slug change. We already show the permalink on the subsequent page, so it seems unnecessary to show it in both places:

And reducing the text here would not only benefit the information density (allowing more pages to show), but would benefit dyslexics and others.

Finally, can we get the page-list tree-structure in there? I feel like it's a real limitation to only show the 3 most recent pages. When you build out your navigation, you'll constantly see those 3 same static pages, even if you have a structure of 20 to build.

[jameskoster]

The permalink can be a useful identifier when a search returns different types of content. That said it is kind of doing the same job as the icon. There might be a way to combine?

I agree that 3 seems like too few, but it's probably unrealistic to display all pages, there could be thousands.

[jasmussen]

We can use icons to differentiate there, maybe?

[jameskoster]

The tricky thing with icons is that different post types can have taxonomies with the same name. E.g. post categories and product categories. So if you have a "Pizza" post category and a "Pizza" product category, you'd need different icons in this UI to understand the difference, lest you end up with:

I can't really see a way for core to cater to all custom taxonomies, and relying on plugins to supply icons could end up getting messy.

Icons just seem much less scalable / reliable compared with text, but perhaps there's a smart solution for the icon issue that I'm not seeing?

[jasmussen]

That's a fair point with regards to search, and if we need further differentiation there (such as slug), that seems fine, but to me the information density of being able to show almost double the amount of pages in the initial page filter seems worth it, no?

[jameskoster]

being able to show almost double the amount of pages in the initial page filter seems worth it

If we aligned the context-chip horizontally with the title then the menu item footprints would be identical:

We might not even need to display the context-chip / icon in the initial view given the 'Recent pages' heading. It's only really important when searching.

[getdave]

Icons just seem much less scalable / reliable compared with text, but perhaps there's a smart solution for the icon issue that I'm not seeing?

I think we will also need to consider the a11y of using an icon alone. Why not combine icon for the "kind" and then text for the specific type? I guess it might be too much?

If we aligned the context-chip horizontally with the title then the menu item footprints would be identical

@jameskoster for these mockups would it be possible to include a variety of different titles for the results? Speaking from a long experience of working on this component, if we can add some variety it will help us iron out some of the problems that having long titles alongside long category names could expose.

....being able to show almost double the amount of pages in the initial page filter seems worth it, no?

We need some way to improve both the quantity and the quality of the results shown but also how these are displayed to the user.

---

@SaxonF Thank you for the work on these designs. Much appreciated. Here are my thoughts such as they are:

• What does All pages do when clicked?
• If a link has already been created and submitted, what is the state when you click on that link again? Just want to be sure I'm understand the visuals correctly.
• Related to the above, currently the component fetches "Rich" previews for links which can be very helpful when you have links to external services. How do you see that fit into these designs?
• Link to Media - it would seem nice to show a rich preview of the media in question. This could be aligned nicely with the point above regarding rich previews of links.
• What's the motivation behind moving "open in new tab" outside of the settings? I'm not against it, but is it because you feel it's such a common action hiding it is a bad move?
• For the settings in the drawer I think we should plan into the design for a slightly more technical description to appear below the "user friendly" description of the setting. I know there will be technical users who will want to know exactly what they are adding to their links (e.g. rel=nofollow) or whatever.
• FYI I've been thinking a lot about being more strict about what we consider as a URL. Currently if someone types in "socks" then the UI will allow them to create a custom link for socks and under the hood it's turned into http://socks which is clearly pointless. I was thinking of making it a requirement that we have at least a tld (e.g. .com) or something to indicate that it's a "real" URL in a practical sense rather than a purely theoretical sense (as is currently).
• There's been a lot of confusion with the process of knowing when a link is "submitted". Are we all in agreement that until you hit "Add" (or whatever) no changes to the link are persisted. So if I toggle "Open in new tab" but don't hit "Add" it will be lost. As a result, we will need to make sure that the "Add" button is not active until a change has been made to the link.

[getdave]

cc'ing @alexstine and @joedolson for input on the accessibility of these proposed changes to the design of the Link UI. As they are currently in Figma only, if there's anything we can do to help to make these designs perceivable for you please let us know.

[joedolson]

Using only an icon to differentiate between different types of links is going to be very difficult to use, especially on large sites with a lot of taxonomies (as mentioned above.) I don't think it's worthwhile to display more items if the cost is the inability to distinguish which one is right.

[SaxonF]

What does All pages do when clicked?

This should only be visible in navigation block and should add a page list block.

If a link has already been created and submitted, what is the state when you click on that link again?

It should open this state where you can edit or remove the link, Clicking edit takes you back to the original state, pressing esc or input blur should show token again. "Add" action would change to "Save" (or adjust) if you're editing rather than adding.

Related to the above, currently the component fetches "Rich" previews for links which can be very helpful when you have links to external services. How do you see that fit into these designs?

Yep we can still show rich previews which would appear below token like we currently do.

What's the motivation behind moving "open in new tab" outside of the settings? I'm not against it, but is it because you feel it's such a common action hiding it is a bad move?

This was based on recent feedback which does suggest it was too hidden for such a common action. @annezazu might be able to link to some of that feedback.

FYI I've been thinking a lot about being more strict about what we consider as a URL. Currently if someone types in "socks" then the UI will allow them to create a custom link for socks and under the hood it's turned into http://socks which is clearly pointless. I was thinking of making it a requirement that we have at least a tld (e.g. .com) or something to indicate that it's a "real" URL in a practical sense rather than a purely theoretical sense (as is currently).

Some url validation probably makes sense although would there be edge cases to handle? e.g. localhost or #my-div

There's been a lot of confusion with the process of knowing when a link is "submitted". Are we all in agreement that until you hit "Add" (or whatever) no changes to the link are persisted. So if I toggle "Open in new tab" but don't hit "Add" it will be lost.

I missed some previous discussion around the addition of cancel/save but makes sense to me to only persist once "save" is hit.

[SaxonF]

Finally, can we get the page-list tree-structure in there?

@jasmussen perhaps we show first 10 or so pages based on order? In future we can get smart with what suggestions we show e.g. for inline links default search is the text you've selected.

I'd treat page suggestions as its own isolated task since recent is current behaviour.

[jasmussen]

perhaps we show first 10 or so pages based on order? In future we can get smart with what suggestions we show e.g. for inline links default search is the text you've selected.

Definitely a separate issue, fine to iterate. But just thinking further ahead, it seems good to figure out whether we eventually show the tree view or always show the most recent items. For a static stie that hasn't had new pages created in a long time, it really feels awkward to see recent pages there.

[annezazu]

This was based on recent feedback which does suggest it was too hidden for such a common action. @annezazu might be able to link to some of that feedback.

I definitely have sent folks to this issue who have mentioned how hidden open new is as a pain point and I myself have run into it! Let me tag in some folks from the WordPress.com side as they can often bring in at scale feedback (including some data that we can't get otherwise) to the project as a contribution. cc @jordesign @supernovia for any insights you can possibly share.

[supernovia]

Ah! Now I understand more about why these changes were made. I'm hoping they can be refined a bit. Here's a wildly popular forum topic on how to make links open in a new tab. People haven't previously asked support about this terribly often, but they do find that answer 10K+ times every month. Here's a video I made to show my before/after, if it helps (this video has sound, but you can see the before/after without sound if needed):

adding.a.link.in.a.new.tab.mov

From our forums, about this update:

they make us click an extra button to turn text into a link that opens in a new window. Why? That button only gives us that option. It’s not like there are other things it offers. That button was where the “open in a new window” button had been. Why make it harder to do that?

[jordesign]

I have a few qualitative comments from folks running into this change as users on WordPress.com...

"Yes, Whenever I insert a link, I apply the feature that says open in new window. If I dont apply that, the visitor will click on the link and the linked story will open in the same screen, instead of another.That feature is not available as of today :-("

User effectively thought the feature was removed, rather than just 'moved'

"I was just trying to update the sidebar on our home page and when I inserted a link - in the PAST it would let me choose if I wanted to have it open in a NEW page. I do NOT see that option now??? Why?"

"The facility to open a hyperlink in a new tab seems to have disappeared?"

[getdave]

Right so we need to consider making the Open in new tab visible at all times. Got it 👍

Btw this is additional evidence for why we need to consider revisions to the Link UI as a dedicated project rather than ad hoc efforts. That's what we're doing now with this Issue.

[getdave]

Some additional design work happened at #49873 (comment). We need to unify this with the discovery undertaken here to ensure we're thinking holistically about the Link Creation UI.

[hz-tyfoon]

Hey everyone.

Super excited to share after spending few hours on going through the conversations and understanding the codebase I created this PR #50401 where a issue is fixed and I believe the UX is slightly better than shown in the video by @supernovia

I demonstrated the fix in a video in & commented it in my PR.

Everyone's review will be highly appreciated 😊. Thanks 🙏

[getdave]

Update

We have new proposal for a refreshed UX and Design for the Link UI. This is to better support the various context in which it is required.

[richtabor]

Closing this as most of these linked issues are either completed, or tracked in the LinkControl tracking issue.

Solid progress. 🚀