-
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
Sidebar permalink panel: consider to always render the panel #12031
Comments
Also, if I remember correctly, it was decided to remove the permalink UI in the post title. Not sure it's already tracked down in some other issue. /Cc @youknowriad |
Removing the permalink UI in the post title had my preference but I think there were some hesitation. I'd love thoughts from others @jasmussen @karmatosed @mapk @chrisvanpatten @earnjam |
I'd vote for removing it. It has serious accessibility issues. I'd say also usability and discoverability aren't ideal. |
Worth reminding this issue with more details about the a11y issues: #5494 It was closed only because there's now the new panel. However, the old UI is still not accessible.
|
Considering the flow that a casual user might want to dismiss the sidebar and never open it again, it would be nice if the permalink was editable in the pre-publish flow (i.e. press Publish... and the permalink could be a panel there). If we had that flow in place then it would be harder to find good arguments to keeping the current in-canvas interface in place. |
#12009 has ability to edit at any time and would resolve this issue. It has permalink sidebar panel visible but not expanded on initial load. If that lands it would also make adding a permalink editor to the pre-publish panel pretty easy. It would be hard to do without it because if a user publishes without first saving a draft, we don’t know the permalink structure. Main consideration is it requires 2 core changes. I’ll work on it today and get patch up for the 2nd core ticket. I also need to make a small update to the PR so it can work correctly in the plugin until the core patch lands. |
I believe our publishing flow causes a bit of confusion here. I've seen more than one occassion where the user clicks the Publish button expecting to publish the post regardless of the ellipses at the end of the button or not. It's surprising to them that a pre-publish sidebar appears, and I've seen them just quickly click "Publish" button again thinking something went not as expected. That being said, having the Permalink section in the Doc Inspector makes more sense to me. This way a user wouldn't have to commit to "Publishing" their page before seeing another sidebar that allows them to make that adjustment. My vote is to keep it in the Doc Inspector, and to show it from the beginning as suggested by @afercia in this issue. |
Yep, also from an accessibility perspective the behavior of the Publish button / panel is a concern. The first implementation was discussed at length in #4187 and improved a bit. Still, the way the three steps work can be highly confusing for assistive technologies users: something appears on the page, focus is moved there unexpectedly, there's nothing to inform there are publishing options before getting there, etc. Also, worth nothing the pre-publish checks can be disabled. Placing important settings only there is not advisable because if users disable this panel, some settings could be completely unavailable: Out of the scope of this issue but maybe worth trying to revive the explorations on #7602 /Cc @mapk |
@jasmussen I know, but that's not the point 🙂 Was just advising to not put the permalink UI only in the pre-publish checks. As I see it, the pre-publish checks should contain only optional suggestions and not important features like permalinks. |
Of course they should be redundant UI, I hope no-one has suggested otherwise. |
@afercia, I believe @jasmussen was just suggesting adding a way to edit permalinks to the pre-publish panel to support removing it from the title area. The sidebar panel would remain. Similar to how visibility and date are done now. |
Yes, absolutely. To clarify because there was confusion (sorry about that):
If we remove it from the editing canvas and have it only in the sidebar, then users who never use the sidebar won't have access to it. By putting an extra copy of the permalink UI in the pre-publish check, it can be a "last minute" way to tweak those final things before publishing. |
In the post-publish check it's already "too late" in many cases to change it. For example a plugin might have already shared the post on social media. What would be the problem to solve? Similarly, the post address is a grayed field because the intent is for you to be able to copy that link directly and share it wherever you like, because it's now live. The UI isn't necessarily perfect for it, but that's the history of how we got there. |
There are redirects to solve this issue. Also, the permalink can be edited at any time after the post has been published, and the permalink structure itself can be changed at any time. WordPress takes care of this.
SEO for example. As an user, I might realize my permalink is not ideal only after I published the post and want to change it.
Not arguing if it's grayed / readonly. I argue it displays the first part of the URL, which doesn't help me at all. I don't need to see my address starts with (in this case) |
Although that can work, it still feels slightly confusing to suggest the permalink can be edited after the fact, and if it's that important for SEO then seems worth giving more presence to the panel in the pre publish state. Regardless, both those screens should be heavily pluggable so plugins could do this. Could we make the link field wrap instead of crop the URL? Seems like it'd be misleading if the copy button copied the full URL but only a part of it was shown. All of the above is separate to this ticket though. |
Chiming in to say that I supremely dislike the inability to see/edit the slug prior to saving a post or page with a passion. As a more advanced user I find it so counter productive to name a page/post, know that I want to customize that slug to something specific, and have no way to do it other than publishing (i.e Publish/Pending) and then go back and edit it. It's just extra unnecessary disruptive steps. |
I'm good with showing the Permalink module in the Document Inspector at all times and from the very beginning of creating the draft. Maybe we just set default to collapsed. |
Regarding the old permalink UI (the one above the title), worth reminding #5494 is still open and waiting to be solved since March 2018, which is two years now. The old UI has inherent accessibility problems, starting with its placement before the title. At some point it was declared deprecated. Long time has passed since then and we were only waiting for a new UI to be complete and fully functional. We should now either remove the old UI or change it drastically to solve all its issues. |
Splitting this out from #11874.
When creating a new post, the new permalink panel introduced in #11874 is not rendered yet in the sidebar.
The panel appears only after the first auto-save or after users click on "Save draft" or "Publish".
This could be confusing for users who are just exploring the new post screen and wondering where the permalink setting is. It could be even more confusing for screen reader users, as screen readers have special tools to explore a web page (e.g. list all the headings, list all the form controls, list all the links, etc.) and they won't find anything related to the permalink setting. Same potential confusion applies to low vision users, screen magnifier users, users with cognitive impairments, etc.
I'd suggest to consider to always show the panel in the sidebar with some meaningful message when a slug doesn't exist yet.
The text was updated successfully, but these errors were encountered: