-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Publish flow: Remove tag and post format suggestions from pre-publish panel #16310
Comments
I really like the idea of trimming down this. I am not totally sure it makes sense in the flow adding tags there, it would be great to remove and see if there's feedback it was useful, then find a better place for it. |
Agreed! For historical reference, the tag suggestions were added to the pre-publish panel (along with post formats, which I forgot about entirely but I think may still be there) in #7426 in order to help users find things they may have missed. Given the pre-publish panel already can give people the jitters—and all of these things can be altered post-publish anyway, I've added the tag suggestions to the post-publish panel in #16341, but I'm certainly not opposed to removing them entirely if they aren't getting much use. How could we best determine if people are making use of these suggestions? |
Yep, as you proposed in #16311, I'd totally agree to keep the pre-publish dialog super lightweight and focussed. 👍 Yep, the post format suggestion is still there: you need to activate a theme that supports post formats (e.g. Twenty Thirteen), make a post with a video, et voilà: |
It sounds like we should remove both here then, in the interests of keeping things super focussed and useful. If anyone has any data to support that tag suggestions and post format suggestions are helpful, please share, but I'm going to run with the assumption that we can try to simplify things by removing them. If we hear user feedback that they miss the feature, we can always add them back in. |
I'm late to this, apologies. I would keep the tags there, and even consider removing them from the sidebar itself. If the problem is visual weight, they can be collapsed or minimized. The Document sidebar is currently a bit of a kitchen-sink of classic WordPress features such as tags, excerpt, featured image and others that could be reconsidered and better integrated in the normal editing flow (one that was less desktop centric too). The sidebar can also be dismissed, which was the reason initially for adding the tags there: give a last-minute opportunity to check up on important metadata before publish. Tags and categories are items you usually configure when you're done writing the post, just before you're ready to publish. Having them permanently surfaced in the sidebar does not substantially help the flow. As a parallel, the sidebar itself has received a fair bit of accessibility feedback about the number of tab-stops to get there. While that aspect has received separate attention and deserves more, it does seem counterintuitive to remove tags from a modal that captures focus, in favor of keeping them in the sidebar. I would suggest either postponing removing the tags from the pre-publish flow until we can revisit the document sidebar in a more holistic way, or just go straight to removing tags from the sidebar and keep them in the pre-publish flow only. |
I think it's important to think of this issue in terms of what we know now, it's been a long time since for example my comment here. Back then we were thinking of different ways of having the publishing flow, as those don't exist now and more exploring is happening. away from the sidebar, I think I agree with @jasmussen. |
In order to focus attention on the most important parts of the pre-publish checks, I'd like to propose removing the tag suggestions.
Before (note: theoretical design, see #7602 for context!):
After:
If we want to provide tag suggestions, it may make more sense to include them instead in the post-publish panel, so that we can really focus users' attention here on the most important part of the publishing flow and keep distractions to a minimum.
The text was updated successfully, but these errors were encountered: