Is the post publish sidebar necessary?

[richtabor]

I've had it on my list to fix the buttons on the post publish sidebar (https://github.com/WordPress/gutenberg/pull/53245) — but in doing so I started questioning if this view is even necessary.

• If you don't have pre-publish checks activated, you'll never see this sidebar view anyhow.
• There is already a snackbar notice for viewing post publishing.
• It's not that helpful, other than copying the permalink.
• The pre-publish check view could just slide back out of the way once you hit the publish button.

Thoughts?

Visual

Recording

https://github.com/WordPress/gutenberg/assets/1813435/e61d147d-012e-4c66-bc1e-8b801fdea0a3

[carolinan]

Personally, I find this sidebar disruptive and always turn it off; I wouldn't mind if it were removed. Two things:

1. The notification may disappear or move too fast for some users and be more difficult to target for others.
2. Depending on if the editor is in fullscreen mode or not, there is no second "Add new post" option.

[richtabor]

Yea the thing about both of those, is if pre-publish is disabled you don't get either of those.

I think the pre-publish checklist is fine to keep — just not sure if post makes much sense.

[hanneslsm]

I would also welcome it if the publish sidebar was removed.

But I think the quick access to copy the link is quite handy, I wouldn't want to miss this. We could add it to the Page → URL?

[jasmussen]

Going back to the origin of the sidebar, the goal was to provide a pre- and post- publish flow so that people can:

• Avoid accidentally publishing content by providing an "are you ready?" check.
• Check important last minute things before publishing.
• Get access to useful next steps after publishing.
• Celebrate the fact that you succesfully published.

In both the pre and post publish flows, plugin extensibility was a crucial part, but largely, the only thing I think has been successful in all of this, was to avoid accidentally publishing things.

In that light, I think there's a lot of untapped potential in both flows, potential that if addressed through a proper design and dev iteration would probably make it less likely for people to want to turn off this flow. So I feel that although perhaps it isn't necessary, that it's premature to discard the concept. I'm aware that this issue focuses primarily on the post-publish flow, but I thought it important to mention its shared origin with the pre-publish flow.

To differentiate between the two, the pre-publish flow is definitely the most important one, and even that is not yet fully realized. Outside of extensibility and preventing accidental publishing, I see a strong opportunity here to further extend the core check-up aspect, as it is a solid interface for surfacing:

• Accessibility issues (there's an incorrect heading level, or a contrast issue)
• Link issues (there's a dead link)
• Block issues (your "Maps" block is missing an API key)
• Template issues (your Navigation menu has been deleted)
• Other issues (your template is set to use the "Cabin" font, but the font is not installed)

That scratches just the surface of the pre-publish potential, and the post-publish flow feels like a natural extension of that. Essentially if the pre-publish flow asks if you're ready, the post publish flow celebrates the fact that you published. And that's worth celebrating.

[richtabor]

To differentiate between the two, the pre-publish flow is definitely the most important one, and even that is not yet fully realized. Outside of extensibility and preventing accidental publishing, I see a strong opportunity here to further extend the core check-up aspect, as it is a solid interface for surfacing:

Agreed!

Do you think post-publish should be available regardless of whether pre-publish is enabled?

[jasmussen]

Do you think post-publish should be available regardless of whether pre-publish is enabled?

Perhaps a decision there is best driven by a design iteration, which would be useful regardless since the whole panel becomes a dialog when in the site view. Depending on where such an exploration lands, the differentiation between pre and post-publish flows might become less meaningful, simply becoming a single "publish flow". Or the post-publish prompt might indeed disappear entirely, or simply become a snackbar after the fact.

[MadtownLems]

We've done our best to disable pre-publish checks for our content providers since Day 1, which is unfortunately not incredibly easy and pretty hacky. Our user testing demonstrated the exact concern we had: people assumed their content was published after clicking, when it wasn't.

The individual pre-publish checks that are included also leave a lot to be desired and are incredibly complicated to customize. Were it easier to customize them, I'd likely have found more merit in adopting and educating on them. Without going into too much detail as to what's wrong with them, but just to give some examples:

• We don't want our users wasting their time or energy on Tags (it's taken years to get people to stop adding 100 pointless and redundant tags to every post.)
• What would be nice would be things like: "Consider writing a custom excerpt". "This is a top-level page, are you sure it shouldn't be a child page?" "Don't forget to choose a Featured Image." (or actually prevent publishing until you have one) "You used one of the Block Patterns we provided but didn't update the image from the placeholder. " But again, customizing the pre-publish checks is a herculean task.

At a minimum, it should be trivial to programmatically disable pre-publish checks for an environment (not relying on user preferences). This is the perfect example of the kind of thing that was always very easy to customize with filters in the classic editor but remains difficult or impossible to control in Gutenberg.