Unify publishing flow between post and site editor

[ntsekouras]

#52632

While started working on unifying post status panel between post and site editors here, it was quickly clear that what we need to discuss is the different publishing flow between the two editors, and see if we can unify it.

The unification would include:

1. Publish or save button
2. Revert to draft button
3. Post Status panel
4. Post Visibility panel - it's included in some of the designs of the new inspector controls along side with status. Is this correct? What we should update to that panel?
5. Post publish flow

Maybe it makes more sense when writing posts, to want to publish with a single click whereas in the site editor that might not be always good, so we should have a separate post status panel.

[jameskoster]

This is a topic that can quickly blow up when we consider multi-entity saving, but for now I think it makes sense to conditionally replicate the post editor experience in the site editor.

IE: If you're editing a post or page with status "draft", and nothing else has been edited, then:

• Include a 'Save draft' button
• Include a 'Publish' button
  • On click opens the 'pre-publish checks' panel
• Show the 'post-publish' panel on publish

Here's a mockup:

Later on we can investigate migrating the save experience to a modal (to be consistent with saving in Site View), and updating the pre/post-publish panels so they are able to entertain bulk-publishing.

[ntsekouras]

IE: If you're editing a post or page with status "draft", and nothing else has been edited, then:

• Include a 'Save draft' button

This diverges from what we have right now in post editor, as we always show it. Is that fine to make this change and also affect post editor? It will affect how the reused component will be implemented.

[jameskoster]

Oh good catch, there's some additional nuance. For one thing it's not possible to manually change the status in the post editor, but you can in the site editor. In the post editor it seems the status is automatically inferred from the publish date.

IE scheduling a post (when you click the "Schedule..." button) will switch the status to scheduled automatically. Until then you can continue to save as a draft.

In the site editor it's different because you can manually change the status. So you can set a future publish date, but unless you also change the status to scheduled then the status will remain as draft. The publish date will arrive, and the post will remain unpublished. Seems there's an opportunity there to prompt the user to change the status.

Anyway, following the suggested logic... if you set a future publish date but do not change the status to scheduled then the 'Save draft' button would continue to be actionable. I think that's okay. As an addition, perhaps if you set the status to scheduled then the "Publish" button should read "Schedule...", and open the pre-publish checks. Once the status is changed (from draft to scheduled) the 'Save draft' button disappears. What do you think?

Edit: There's the pending status too 🙃. In that case the "Save draft" button can read "Save as pending".

---

Clearly it seems there's some refinement we can do to improve the interaction between publish date and status in the site editor. At the minute it's a bit strange that you can create contradictory configurations, e.g. Set a publish date in the past and set the status as scheduled. Or set the status as published and choose a publish date in the future. There are the visibility settings to consider as well which have some overlap.

[jameskoster]

Here are some refreshed designs for how we might update the experience in the post editor, in a way that can also be implemented in the site editor later.

Draft pages

• Separate “Save draft” and “Publish” buttons.
• “Publish” button opens the pre-publish checks where you can schedule and adjust visibility.
• Status chip appears above featured image.
  • Clicking status chip opens a menu with actions to changes status.
  • "Publish" and "Schedule" actions open the pre-publish checks.
  • "Switch to pending" updates the chip label, and "Save draft" button becomes "Save as pending"
• Publish date remains a separate item.
  • Ideally it should not be possible to set a publish date in the past as this leads to contradictions between publish date and status.
  • When a future publish date it set, “Publish” button should read “Schedule...”
• Password is a separate item

Published pages

• “Save” button saves the page instantly
• Status chip and split button open a menu with status change options
  • Split button can be omitted in initial implementation
  • Each option opens a confirmation modal
  • On confirmation the page is immediately saved

Multi-entity

• Save button references number of changes.
• Multi-entity UI moves to modal.
• If a page is selected to save the status / publish date can be modified.

[jameskoster]

@ntsekouras There's still some longer-term refinements to be made around the publish flow(s), but do you think we're in a state of unity whereby this issue can be closed?

[ntsekouras]

Let's close it, yes. I've opened a new one for technical refinements and let's create another one for the refinement of the flow and UI in order to keep the technical improvement separate.