-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Restore the terms 'Permalink' and 'Slug' in the PostURL user interface #61196
Comments
For some history: at the beginning of this Gutenberg project, the 'Permalink UI' has been discussed at length. To make an informed decision, I would suggest everyone to do some GitHub archeology and read the discussions on the issues and PRs related to the permalink UI. The root issue with the permalink UI is that the post URL may be very long. In order to show the full URL, the permalink UI should be placed in a spot that provides sufficient width to show long content. The settings panel is, by its own nature, limited in width. As a consequence, efforts have been made to attempt to display the permalink in a 'smart way', which resulted in truncating the text. However, that is less than ideal. In 6.5., this (truncated permalink in the settings panel): Is clearly less usable then the UI in the Classic editor, which does a better job to show long URLs: Also, the Classic Permalink UI uses some smart handling of long URLs to attempt to display only the relevant parts, as explained in #61158 Basically, until 6.5 the Gutenberg editor hasn't solved yet this problem and users can't see the full permalink in the UI. The latest changes on trunk make things worse because the UI now shows only the slug. There is no way to see the full post permalink. I would say that, even before any accessibility consideration, this is a serious usability and design issue. I would like to suggest to use some lateral thinking and try to solve the root issue instead of the symptoms. Rather than trying to 'squeeze' the content in a limited-width UI, I think it's time to consider to move the permalink UI to a different place. A place in the editor UI that provides way more horizontal space. Clearl, not a side panel. |
Additionally, also the toggle button that opens the PostURL popover is labeled incorrectly. Imagine you're editing a post with title 'Hello World'. The toggle button that opens the popover will be labeled with |
@afercia just coming to this as I agree it's harder to edit the link of a post in the new experience and have added it to the new tracking issue for writing experience. |
Thank you @annezazu 👋🏽 The UI is slightly changed on latest trunk, still the terminology in use could be improved. I'd also like to note that the 'Learn more' link leads to a documentation page that is oud of date. It still shows the old UI and it should be updated. Screenshot of the latest UI on trunk: Screenshot of the documentation page that needs to be updated: |
I really don't see why this issue is still lingering; the label is just wrong as is, and needs to be updated. I feel like it's driven by a desire not to use words that require technical insight to fully understand, such as 'slug'; but that's a disservice to users, as we're instead using a word that is not what they're editing. It is not difficult to learn what a slug is; the text that currently explains that a user is actually only editing the last part of the link would be perfectly accurate as a description of 'slug', instead. |
Just noticed: passing the whole link as the help prop of the input field is very arguable and highlights there is no understanding about what a description for an input filed is supposed to be. An input field description, associated with aria-describedby, is meant to provide a meaningful explanation of what the input field is about, or instructions and hints. It's not a place where to use a value. I'm guessing this has been done only for visual purposes, to place the link below the input field. Semantically, it's just plain wrong. |
One more thing to fix: when the compoent shows the non-editable front page link, the aria-label still says it can be 'changed' even if it's not editable: |
The "Link" label can be even more confusing depending on the permalink settings. For example, select "Custom Structure" as the permalink structure and enter The button text in the panel will show |
I would like to propose the following UI. All permalink structures have the following in common:
Custom Structure: Post nametrunkProposed UICustom Structure: Custom (/%post_id%/)trunkProposed UINote that there is no "Customize the last part of the URL." text because when the custom structure is a post id, the slug is not part of the URL. |
@t-hamano good point. And it's not limited to the
In this case, the Classic editor only shows the Permalink with no UI to edit (because there's nothing that can be edited): Instead, when the permalink contains an editable part, the editing UI does show up: I'd think you're right and the UI logic should be reversed: the Permalink should be the value that is always shown, whether it is editable or not. The slug may be part of the Permalink and should be shown only when it is editable. The only problematic point I see is that the Inspector panel isn't the right place to show the full permalink because it may be very long. As a user, I want to see the full permalink to check it's a good one that make sense for my post. Which brings us back to old discussions for example in #577 and in #5494. Still, I'm not convinced the Edit permalink UI should live in a narrow panel. |
@afercia Thanks for the feedback.
This is a bit confusing, but the slug is editable in the classic editor even if it's not part of the permalink. If you open the Screen Options and check "Slug", an input field will appear below the content editor: So in my opinion, the slug should always be editable in the block editor, whether it's part of the permalink or not. But maybe this should be discussed in a separate issue. |
This issue may be related to #56381. |
Yes, this is something to consider. Overall, I think the current UI doesn't provide users with the best experience. Weirdest case is when the permalink structure does not contain the
|
Is it necessary to call it two different things: permalinks and slugs? I don't thing the panel should be different from the input (visual label or not). |
Seems Slug is a better fit than Permalink. |
The terms "Permalink" and "Slug" need to be used clearly. An example of the definition of the terms is quoted from this webpage:
|
Right, so in this case the label should be Slug, right? It’s confusing calling the setting in the Inspector Permalink, but you edit the Slug. |
It makes sense to me; what you're being shown (the URL), is the post permalink; but the portion of it you can edit is the slug. So the popover can reasonably have a heading for 'Permalink', since it's showing you what the permalink is for the post, but the input field should be slug. |
This may be admittedly confusing, but I think the label (not the popover title) should be "Permalink". Because if the permalink doesn't contain a slug, the slug doesn't mean much: If we change the label to "Slug", the UI would look like this: Additionally, I find it odd that the permalink is displayed in a popover that opens when I click a button labeled "Slug". I'm still leaning towards the UI change suggested in this comment. |
I'm comfortable with the UI change suggested there, @t-hamano. |
I'm not confident just yet. What's the formal proposal to change it to? |
I've moved forward with what was suggested in this comment and pushed it to the enhance-post-url-ui branch. The changes are as follows:
These changes take into account the proposed designs below, but could be improved upon:
Permalink structure: Post namePermalink structure: Day and namePermalink structure: Plain |
It does seem a disadvantage to have |
I think there are some other comments elsewhere about what to show in link editing, and those might be worth reviewing. I think we tended to come down on needing to see the unique portions of a URL more than the non-unique portions; e.g., showing the slug in the Inspector would make sense to me, as well. The permalink label is informing us that this will edit the permalink; since we can't possibly see the entire URL in that space, it makes more sense to me to see the slug. This change might have been driven by Andrea's comments in #61196 (comment); but I think the intention there is to change the aria-label, not the visible label. E.g. instead of "Change link: /hello-world", "Change slug: /hello-world". There are still outstanding issues about using the value as the button text; but there is a separate issue for that. |
So, should we keep the labels and button text as they are and focus on improving the popover in this issue? In other words, the UI will look like this: I think we can discuss the labels and button text in #63992. |
I assuming you're referring to the text 'Link' in the post summary controls as the Label in this context; I still think that should change to Permalink. That'll provide textual consistency between the panel and the popover. |
Description
Splitting this out from #56381 (comment)
In #60632 some long-established temrinology regartding the 'post permalink' has been changed. I'm not sure there has been a broader discussion to validate whether these changes are any good for users. I'd liek to start a broader discussion about that.
Current state on trunk, where the new UI uses the term 'Link':
While I'd agree that, if I had to explain tp a complete newbie or to non-tech-savvy users what to edit here, I would use the most simple phrasing e.g. 'Edit the post link', I'd also note that, for ages, WordPress has been using its own specific terminology:
Permalink
The term 'permalink' has been for ages one of the most prominent terminology used in WordPress. For years, it appeared right below the post title, in a very prominent place:
Even though it's a somewhat 'technical' term, WordPress users are very familiar with what a 'Permalink' is.
The admin menu uses the same term under Settings > Permalinks at wp-admin/options-permalink.php
Slug
The term 'Slug' or 'URL Slug' has been used in WordPress for ages as well. I can count around 30 occurrences of the term 'slug' used within transtlatable strings.
Sometimes this term is used for objects other than a post, such as plugins, widgets, patterns, font collections, etc. Regardless, it's a widely used term and WordPress users are familiar with it.
Concerns
#60632 changed the terms used in the 'edit permalink' user interface after very little discussion. I'm not sure such changes should be done that lightly. I'm not aprioristically opposed to changes but I definitely think changes that impact long established conventions should be validated by user testing. In absence of user testing that validates the proposed change performs better, we should just avoid to introduce such changes.
In this specific case, personally I don't see a good reason for this change.
Also, I'd like to point out the new terminology 'Link' is technically incorrect. Both in the settings panel and in the popover, 'Link' is now the label for the last part of the URL However, in this UI, users can edit the last part of the URL. they can't edit the 'Link'. In everyday's language, although a little incorrectly, the term 'Link' is used to indicate the full URL.
Overall, my question is: why change these terms? In which way this change makes the user experience any better?
I would say a more wise approach would be to not change long established conventions. Although both terms 'permalink' and 'slug' are a little technical, to me there's no good reason to stop using them. Rather, the Editor UI should a better job to explain new users what they are about.
More screenshots of the admin UI where the Permalink and Slug terms are still in use:
Step-by-step reproduction instructions
Screenshots, screen recording, code snippet
No response
Environment info
No response
Please confirm that you have searched existing issues in the repo.
Yes
Please confirm that you have tested with all plugins deactivated except Gutenberg.
Yes
The text was updated successfully, but these errors were encountered: