Improving the UX around invoking the LinkControl popover

[richtabor]

I'm exploring ideas for improving how LinkControl functions within RichText, particularly around invoking the LinkControl popover. I wanted to bring up this approach that Slack uses for links, that I think is interesting.

Current

The current implementation in the editor:

• Uses the block toolbar button to create a link, if a link is not selected.
• Uses the block toolbar button to "unlink" a link, if a link is selected.
• Invokes the LinkControl popover, if you select/click a link.
• Invokes the LinkControl popover, if you use the keyboard to move your cursor onto the link.

Here's a video observing those behaviors:

link-2.mp4

Proposed

The proposed implementation:

• Uses the block toolbar button to create a link, if a link is not selected (no change).
• Uses the block toolbar button to invoke the LinkControl popover, if a link is selected (change).
• Invokes the LinkControl popover, if you select/click a link (no change).
• Does not invoke the LinkControl popover, if you use the keyboard to move your cursor onto the link (change).

Here's a video observing those behaviors, as seen in the Slack editor:

asf.mp4

What I like about this approach:

• The link/unlink control in the toolbar is never destructive; it always invokes the LinkControl popover (either to create, or edit).
• In the current implementation, we have two "unlink" controls always available at the same time. One in the toolbar, when you select a link. The other in the LinkControl popover, which is always available when you select the link anyhow. Related: Improve LinkControl preview #57775.
• It's generally more predictable.

Why

This is based on accessibility feedback that link editing is not easily discoverable, and UX feedback that the popover can be distracting opening whenever the cursor enters the link:

For a screen reader user, IMO there isn't a discoverable way to edit a link. The toolbar includes an Unlink button, but no Edit Link button. To edit a link they'd need to know the Command + K convention (a common pattern, which is great) or know to press Tab when the carat is on the linked text.

Related comment by @jeryj on #57726 (comment)

One more note and it has been discussed in previous issues but never fixed. When editing a link, you must use the shortcut. From what I can tell, there is only an unlink button in the formatting toolbar and there should also likely be an edit option there for best discovery. It makes little sense that by highlighting text, I would then tab to find a random edit button for my created link when tabbing under any other condition would land me in the sidebar.

Related comment by @alexstine on #54063 (comment):

[jeryj]

Dropping a quick comment to say, at first glance, I really like this approach! Thanks for writing it up!

[joedolson]

This seems like a much more predictable model to me. The use patterns make sense, minimizing unexpected changes of context and also reducing extra clicks. I particularly like losing the unlink button in favor of an edit button; I need to edit a link far more frequently than I need to remove one.

I've also noticed occasional positioning bugs where the link controls cover the text, so you have to remove the link in order to edit the text. This would make the issue irrelevant.