Link UI: Add and edit links directly within the block toolbar

[shaunandrews]

Some blocks, like the Paragraph, Navigation Link, and Button block, require a URL for the block to function. Right now these blocks tend to open addition UI to allow for manipulation of this required data:

You'll notice that the Paragraph block alters the link icon in the toolbar, allowing a user to unlink the selected text. Navigation Link and Button blocks don't follow this pattern, instead clicking on the icon always opens the link UI.

For the Navigation Link block specifically, we've been looking at exposing the URL directly within the block's toolbar (#23023):

The next logical step for this UI is to allow manipulation of the data from directly within the toolbar. As this isn't an isolated need, this issue aims to explore how we could allow for manipulation of URL (or general text-based) data directly from any block's toolbar.

--

The somewhat mysterious link icon is replaced with a more obvious text label; Edit Link when a link has been set, and Link when there is no link set.

If there's a link, hovering over this button for a few seconds will display the current URL in a tooltip:

When clicked, a new Link UI appears with :focus moved to the URL input alongside options like "Open in new window" and a Done button. The Link UI consumes the toolbar, hiding the selected block's buttons.

--

This also touches on some recent work around Reusable blocks and Templates (#23213), where there is often the need to display/change a descriptive name:

[adamziel]

#23023 now contains a super rough prototype of this idea, more progress will come

[mtias]

Really like absorbing the link editing flow in the toolbar for these blocks, it's the natural progression. However, I don't think the link icon is any more mysterious than the other icons in use, and the verbiage clearly starts to break down in the image block example with three text based buttons which starts to affect the ability to scan, in my opinion.

Also I think showing "Edit Link" for navigation menu items is worse than displaying the actual link, which gives me better and quicker information. I think it's fine for the link to collapse to the icon in other cases like images, but for navigation it's the primary element.

[pablohoneyhoney]

Word form of the action only makes sense when it creates a better hierarchy with the surrounding UI, or there’s no better way to describe the action itself. It gets convoluted with various words. Worth pushing the possibilities of the icon, and only use word form when we exhausted the capabilities of the icons.

[adamziel]

A more advanced prototype available in #23023 (comment) - any feedback is appreciated!

[shaunandrews]

Thanks for the feedback above. I've been working more on this and have some progress to share with regards to the Link UI in context of the Paragraph block:

This one uses the link icon as the way to toggle the Link UI, and as a visual anchor for the Link UI's toolbar. Once you start typing, search results are shown — this is similar to the current Link UI, but with some style updates and simplification:

Once the link is added a dropdown icon appears with more advanced options:

There's also a new "linked" state for the Link button in the toolbar, which is shown here with a subtle (maybe too subtle) blue background, matching the blue background we use to highlight links in the block content:

[adamziel]

As the design discussion is still going, I will put my PR on hold for now

[shaunandrews]

Here's a few quick GIFs that shows how this would work on the Button and Navigation blocks:

[draganescu]

@shaunandrews is there a reason there are tiny differences between navigation, paragraph and buttons linking in the GIFs above?

Just to check, what happens when I click the subtly shaded link icon? Do I end up in edit mode or do we show the link like the current LinkControl works?

[shaunandrews]

is there a reason there are tiny differences between navigation, paragraph and buttons linking in the GIFs above?

There are reasons, and I'm sorry I didn't take the time to detail them out alongside the GIFs. The differences mostly come from @mtias' comment above:

I think showing "Edit Link" for navigation menu items is worse than displaying the actual link, which gives me better and quicker information. I think it's fine for the link to collapse to the icon in other cases like images, but for navigation it's the primary element.

What I take away from this, is that some blocks need to prioritize a link's URL while others don't.

For example, the Button block requires a URL to function; Without a URL the buttons don't actually do anything. With this in mind the Button block should show the URL in the toolbar. The same logic holds true for the Navigation Link block.

When these blocks are missing a URL they will instead show the "Add link" label:

Since URLs can get rather... lengthy, we'll need to do our best to remove unnecessary information and truncate when needed:

There are other blocks where the URL is not required, like the Paragraph or Image blocks. These blocks would show the link icon, but not the URL. The URL would be shown in a tooltip when hovering over the icon.

For smaller block toolbars the link interface will increase the width as needed:

The blue background color for the link button that appears in all of the above images is my attempt at highlighting the difference between a block without a URL and a block with a URL. I've included some additional options, including the last option (G) where there is no indicator.

There's a difference between adding a new link, and editing an existing link; Existing links offer a menu for more options, like removing a link and opening a page in the editor. This menu would also be pluggable letting plugins add advanced options like adding a rel attribute or marking a link as sponsored.

[ntsekouras]

The unlink functionality for Buttons has been implemented here: #23445

[pablohoneyhoney]

I don't think the light blues are a clear and contrasting pattern.

[adamziel]

This is too large for a single PR so I decided to split it up into a few separate ones. Here's the first one that makes it possible to replace the default content of the toolbar (ignore the actual form - it's just a placeholder for testing):

#23613

Feedback highly appreciated @noisysocks @shaunandrews @talldan @draganescu

[adamziel]

That PR got approved and is waiting until after beta 1 release (which is scheduled for July 7th). Once it's merged I'll propose the next one.

[adamziel]

The support for "expanded block controls" (as in overriding the toolbar contents) is now merged, the next step here is to update LinkControl and implement the actual toolbar change.

[jasmussen]

There's too much of a visual and spacial difference between where I added the block, and where I'm adding the link.

I believe that's caused by the "parent absorbs child toolbar" prop that is enabled on the Navigation Menu block. I'm a big proponent of that prop as an option some blocks can use — imagine a canvas you can draw shapes on, where ever shape technically becomes a child block you can rotate and skew. It makes sense for the canvas to hold the block toolbar.

However perhaps we should disable that prop for the navigation block, so the spatial connection is reestablished between the selected menu item and the toolbar right above.

[shaunandrews]

so the spatial connection is reestablished between the selected menu item and the toolbar right above.

I've gone back and forth on this a number of times, but that "spatial connection" quickly falls apart when we consider the likely placement of a navigation — close to the edge of the viewport.

[jasmussen]

Indeed that's a good point. I have some early ideas I'd like to explore that might improve this, but I don't think your visualization is so bad it should block the exploration.

[adamziel]

As a side note, I think the toolbar should be constrained to the editor area, by which I mean it's left coordinate should me max( x, 0 ) or some reasonable margin instead of 0. Same for the right coordinate.

[jasmussen]

That should already be the case no?

[adamziel]

@jasmussen of course you're right - I got confused, please ignore my comment :-)

[afercia]

Worth mentioning the proposed pattern, that basically "replaces on the fly" part of the toolbar with another UI still needs to be fully evaluated from an accessibility perspective, as noted in #24805.

There are serious concerns this pattern can be reasonably reconducted to an accessible pattern that provides a predictable, expected, interaction and semantics. To name a few of the main concerns:

• the accessibility team pointed out several times that replacing a portion of the DOM that contains focus with another UI is problematic for assistive technologies and totally unexpected for users
• even for users with no particular accessibility needs, I'd argue the replacing-on-the-fly effect is unexpected, jarring, and adds cognitive load
• semantically, an ARIA toolbar must exclusively contain "a collection of commonly used function buttons or controls represented in compact visual form" while in this proposal it will also contain a form, which is unexpected
• the Gutenberg toolbars implement the arrow keys navigation and the "roving tabindex" patterns, which are the expected interaction patterns for toolbars: the replaced additional UI would break this pattern in the same way it's already breaking it for the Image block "editing tools", see Accessing image block's crop tools with keyboard results in focus loss #24676 and The image block's editing tools break the toolbar keyboard accessibility #24766

Overall, a toolbar is expected to only contain buttons that open menu or "do something". Also important: assistive technology software are designed to understand the ARIA toolbar pattern if it's built according to the specs. Breaking the expected pattern by injecting an extraneous UI within a toolbar would prevent assistive technologies from working correctly thus making the UI not operable by the persons who use that software.

[paaljoachim]

Taking a step back and looking at the current UX patterns.

The above gif shows how we interact with the toolbar. When clicking an icon that contains additional options a drop down is seen.

With the new link control inline editing current version Navigation screen PR:

The UX:

Inline editing is a new UX pattern. Actions happen inside the toolbar. The toolbar changes to show an action.

It breaks the consistency seen in the current toolbar in Gutenberg where one clicks an icon to open a drop down showing additional options. The interaction happens outside the toolbar. The toolbar remains unchanged by any drop down action. Having a non changing toolbar like a mountain can be very comforting. Changing elements are kept outside what is seen as static.

Will additional toolbar actions be brought inline creating a more dynamic toolbar? It feels like inline editing is just one of multiple bigger changes that will make the toolbar more dynamic based on the action being selected. Leaving the consistency of the non changing toolbar to something that reacts to the action of the user.

---

Edit: 17 May 2021. Adding in the following comment as we closed this issue:
URLInput: Include date as context for link search results
#8573
The now closed issue mentions showing the date beside the post/page title. (I like likely added a comment above but since the issue is closed, I am adding a comment again.)
Similar to this example from the Classic Editor like so:

[jordesign]

This issue is still relevant for Navigation items and Images. But in my testing the behaviour is resolved for Buttons.

[draganescu]

In light of the efforts in #50891 is this proposal still open for exploration? The accessibility review here is pretty blocking.

I love the interaction in this design issue - opening a popover from a poover is not the best experience. However switching in and out of these modes echoes the problems in #53852.

cc @richtabor

[getdave]

It's worth noting that this is a different context to #53852. The primary objections there (once I added the visible Submit/Cancel buttons) were from Design and were specifically due to the UI's location within the List View which is a very "busy" part of the interface.

Perhaps in a different context this would be workable. However, I would caution against anyone proceeding here without some upfront design exploration to determine whether or not inline editing in this location is feasible from a Design perspective.

[Mamaduka]

@WordPress/gutenberg-design, is this proposal still under consideration?

It seems that implementing similar design pattern and making fully accessible is the real problem. Ref: #24676, #53852.