Update URL popover

[jameskoster]

It came up in https://github.com/WordPress/gutenberg/pull/56203 that the edit URL popover could use some attention. Here's a mockup that attempts to tidy things up a little:

Changes

• The input label is visually hidden (having both "URL" and "Permalink" seems unnecessary). I think there's a reasonable argument to change this heading to "Slug" – keen to hear thoughts on that.
• Input uses new 40px sizing.
• View page link is now an icon button. I'm not entirely convinced this affordance is needed in this UI – there are more prominent links to the frontend nowadays (details panel, main View menu).
• Added a button to copy the URL.
• Added a / prefix to the input. The idea here is to make a visual connection to the full url without including it (as it could be very long).

[afercia]

A few accessibility notes:

The input label is visually hidden (having both "URL" and "Permalink" seems unnecessary).

Okay, but "URL" now is a sort of 'visual label' while the input field would be labelled "Permalink". While that would work for blind screen reader users, it wouldn't be OK for sighted users who use screen readers or speech recognition software users. The visual labeling must match the actual labeling.

View page link is now an icon button.

Icon-only buttons should be avoided and only used when there is not enough space e.g. in the toolbars. In this popover, there is sufficient space to use standard buttons with visible text.

Also, please let's avoid to visually place buttons within input fields.

Added a / prefix to the input. The idea here is to make a visual connection to the full url without including it (as it could be very long).

I think it is important to keep the full URL visible. While the input field contains only the slug, the full URL must be visible somewhere as it always has been across the history of WordPress. I think this has been already discussed at length since the first implementation of the permalink UI in the Editor.

[ohiawins]

Hola, folks!

Looking at this ticket with @acirujano and we had some thoughts:

• We feel that the current popover in the backend is functioning well with the Permalink field, explanation, and "Learn more." link below and the full URL being linked to the post or page.
• We are both designers and so we love icons but we think they would be better used outside the field perhaps, and we agree with Andrea that they could bring up accessibility issues if left inside.
• We have included a mock-up that includes inline icons.
• We do think the solution for tool-tips (external link and copy link) is an important addition.
• We think that the text should stay but it should be more consistent and spaced better.

We found the popover in the WordPress Design Library and started working on the spacing of the elements, Permalink and View Post/Page. We felt these sections were not separated well enough to give us a visual understanding that they do two different things but are both functions under the URL. So our proposed new layout is below. Also in the backend and in the Figma file capitalization is not consistent so we addressed this issue as well.

High FIVES!! Ana and Ohia

[acirujano]

¡Hola!

This is the mockup that @ohiawins and I made.

It's included on the Proposals page in the WordPress Design Library in Figma.

Ohia and Ana

[acirujano]

Another thing we can consider is improving the titles. Permalink could be Slug, since what the user enters is the slug. And View Post or View Page could be Permalink, which would also be the same title for pages and posts.

Ohia and Ana

[afercia]

Another thing we can consider is improving the titles. Permalink could be Slug, since what the user enters is the slug. And View Post or View Page could be Permalink

Personally, I like the idea of calling things for what they are 👍 The term slug has always been used in the Classic editor and in the taxonomies admin pages. I'd only suggest to name it URL Slug. In the Classic editor, that's the label used for the edit permalink slug field, even though the label is visually hidden:

Also, in the Screen Options users can enable the Slug metabox, which appears below the post content area:

Thats a +1 from me to use the term 'Slug'.

Regarding the 'external' and 'copy' icons, I find a little confusing the former is only a visual indication while the latter is actually a button. Visually, they look similar but they serve different purposes. I'd rather have the Copy button look like a button with visible text. I'd also recommend to bring in some consistency with the 'post publish panel', where:

• The URL field is labelled 'Post address' (or 'Page address' etc.) while for consistency it should be labelled 'Permalink'.
• The Copy button is a button with visible text (which is better for usability and accessibility).

Screenshot:

[acirujano]

Thank you, Andrea, for providing the screenshots to ensure that the term "Slug" is appropriate. The "external link" icon serves not only as a visual indicator but also functions as the external link itself. Nevertheless, I agree with you that the button with the text "Copy" is clearer and more suitable for accessibility. Therefore, I think this would be a better proposal. I have placed the copy button below and not in line because the permalink is displayed in full and can be quite long.

What do you think of this new proposal?

[ohiawins]

• I think if we are going to have such a big button it should say Copy Link.
• In the first solution proposed with our beloved icons we did not include a screenshot that includes the tooltips. @afercia do you think having those would help and then we omit the button for copy?

[acirujano]

I have proposed this button size for consistency (see attached screenshot).

I think it's a good idea to use a more descriptive text, as you suggested, @ohiawins. Perhaps it might be even better to use "Copy Permalink" to maintain the same terminology. I am attaching a new proposal that also takes into account the 2px corner radius on the button.

What do you think? What would work better? The icon with a tooltip or the large button? And one more question: Is it necessary to include the option to copy the permalink?

[afercia]

• In the first solution proposed with our beloved icons we did not include a screenshot that includes the tooltips. @afercia do you think having those would help and then we omit the button for copy?

To clarify what's best for accessibility and, in my opinion, for general usability:

• Always prefer buttons with visible text.
• Icon buttons should only be used when there's not enough space to show visible text, for example in the block toolbar.
• In all the cases where there is enough space, use buttons with visible text as there's no reason to use icons.
• Ideally, all icon buttons should respect the 'Show button text labels` preference and show text instead of icon buttons when the preferences is enabled. Ideally, new design mockups should also provide the 'show text labels' version of the icon buttons.
• When it is necessary to use icon buttons because there is not enough space, icon buttons must always use a tooltip to visually expose the button accessible name. Worth noting the tooltip is a compromise for accessibility: the most accessible applications around show both icons and text.

I like the separated Copy button in the last screenshots. Maybe it doesn't need to be full width and I'm not sure it should be a primary button, but I like it ❤️

For reference, in https://github.com/WordPress/gutenberg/issues/56854 I'm going to propose to change the post-publish panel to use the label 'Permalink' instead of 'Post address' for consistency. Screenshot:

[afercia]

Question for designers @WordPress/gutenberg-design

See screenshot below:

• Left: the current URL popover
• RIght: the current post-publish panel

These two UIs have a few common concepts but use different terminology etc. Besides these inconsistencies, my specific question is about displaying the 'full URL' (also known as 'permalink'): Why in the URL popover it's a textual link and instead in the post-publish panel it's a readonly input field? Is there any good reason to make them different? I'd think it would be better for consistency to use the same pattern. I think we can add a 'Copy' button for both cases, whether it's a textual link or an input field.

[joedolson]

From the accessibility bug scrub on 4/16/2024, we agreed that the design in @acirujano's Dec 8th comment has a lot of great characteristics: it's clear and consistent.

I agree with @afercia that I'm not sure the copy button needs to be full width or primary, but am fine with them as they are, regardless.

Improving consistency by labeling the link accurately throughout the UI would be good.

[afercia]

A few things have changed in the meantime and now the UI on trunk looks like in the screenshot below:

A few notes:

• First of all, the name of this setting changed from 'URL' to 'Link'. They are both incorrect. What users can edit here is actually the 'Slug' or 'URL Slug'. That's the terminology WordPress has been using for ages and there's no value in changing it. Such a change can only have one effect: confuse users.
• In the same way, the toggle button that opens the popover is labeled mentioning the term 'link' with aria-label="Change link: hello-world" which is clearly incorrect as 'hello-world' is not a link. Not to mention all the buttons in the Summary panel are labeled in a less than ideal way but I don't want to rehash the lengthy conversation from https://github.com/WordPress/gutenberg/issues/470 here.
• The input field uses an aria-details attribute. While technically correct, aria-details has poor support. Basically only NVDA and Orca have decent support. There is no great point with using a feature ignoring its actual support. I'd argue this input field doesn't need to reference the paragraph with the full link in the first place. A description such as http://mysite.org/hello-world/ (opens in a new tab) doesn't help and anyways users can still reach the paragraph by other means.
• The 'Copy' button is completely unlabeled. This is one more instance of an unlabeled control, which proves once again the base components are open to misuse Cc @ciampo
• In https://github.com/WordPress/gutenberg/issues/56381#issuecomment-1822590025 I asked to avoid to visually place buttons within input fields. I see that feedback has been completely dismissed and ignored.
• The 'Learn more' link points to an out of date documentation page that still shows the old UI.