Show the post status explicitly somewhere in the UI

[davilera]

If we only had three statuses (Draft, Pending, and Published), it might make sense, as the buttons in the UI somehow let you know the status:

a) If the post is Draft/Pending:

• The main action button is Publish
• There's an action to Save Draft/Save as Pending

b) If the post is Published:

• The main action button is Update
• There's an action to Switch to Draft

Unfortunately, we have one more status: Scheduled. And in this particular case, the UI is extremely confusing:

c) If the post has a Publish date but is not yet Scheduled:

• The main action button is called Schedule... (with ellipsis)
• There's an action to Save Draft/Save as Pending

d) If the post is already Scheduled

• The main action button is called Schedule (without ellipsis)
• There's an action to Switch to Draft

In this latter scenarios (c and d), discovering the status the post is in is complicated: one has to know all the possible combinations of this buttons to "guess" what's going on.

Can't we think of a better solution? The easiest one I can think of is including the Current Status field in the Status & Visibility section (or add it somewhere else, where it's prominent and clear) and probably call the Status & Visibility section differently.

PS. Related (but unfortunately closed) issue #4241.

[stevejburge]

PPS. Also related: Gutenberg has broken support for custom statuses: #3144

This is a key issue for several plugins and SaaS services.
https://pressbooks.org/blog/2018/11/06/pressbooks-and-gutenberg/#2-gutenberg-lacks-functionality-that-pressbooks-relies-upon
https://publishpress.com/blog/gutenberg/

[joemcgill]

I agree that this is confusing. I just had a client update to the latest version of WordPress and couldn't find the "Save" button while trying to edit a scheduled post because the main action button reads "Schedule", which isn't obvious (see screenshot).

[sarahmonster]

My understanding of the problem here—and maybe the cause of some of the confusion—is that "scheduled" isn't a user-set post status so much as it is a dimension of time. A post can have either draft or published status, entirely independently of whether it’s scheduled for a particular date or not.

This may be an issue of the technical structure failing to match users' mental models, and our design and UX echoing those technical constraints.

On a technical level, there are actually 8 post statuses in WordPress, including “future” for scheduled posts.

Solving this issue in a way that matches users' mental models may require a slight reframing of how we think about post statuses.

Available statuses:

• Publish
• Future
• Draft
• Pending
• Private
• Trash
• Auto-Draft
• Inherit
• custom statuses

Recommended to show in UI:

• Published
• Scheduled
• Draft
• Pending Review
• Deleted
• custom statuses

Suggested solution

A post have a status of draft, pending, scheduled, or published*. Not every post will pass through every stage, but any post can go through 1-4 stages on the way to published. My suspicion is that this approach will better mesh with users’ mental models of publishing a post, and providing consistent visual indicators will help users understand where they are in that flow. 🤞

(*For purposes of this flow, let's ignore deleted and custom statuses, since they aren't directly involved with this flow.)

Let’s see how that might translate into screens:

(For comparison purposes, I also have mappings of the existing flow and the Classic Editor flow that I can share, but let's focus on the broad strokes here first!)

Questions:

1. Does this seem like a sensible approach?
2. Should the status be user-editable in the same way visibility is?
3. Do all the label variations help to support understanding of the current status? What about the suggested labels for buttons?
4. Is there any data or usability testing we can use to support our hypotheses here, of either Gutenberg or the classic editor?
5. Should “private” really be a status? (See also Delay private publish #12023.)

[joyously]

Isn't it an accessibility concern to have the main button changing its label?
If there is a place to show the current status and a different place to take action to change the status, does that alleviate the concern?
Maybe the button should only initiate an action and not reflect the current status.

[sarahmonster]

The classic editor uses a similar change of label: "Publish" changes to "Schedule" when the date is in the future, and "Publish" changes to "Update" when the post has already been published.

In this case, where the primary action changes contextually based on user input, that rule may not apply here, but I'll flag this for an additional accessibility check to be sure.

[enriquesanchez]

Isn't it an accessibility concern to have the main button changing its label?

It is when such a change will make the button's label mismatch its accessible name. This is usually the case when you have a menu button, such as the Font Size picker.

The classic editor uses a similar change of label

And we already do the same in Gutenberg. The Publish button label will change to Schedule if I set a future date.

In this particular case, I don't think this would be a problem because:

1. it already happens
2. the label and accessible name match when the change happens:

[enriquesanchez]

This issue was discussed during today's Gutenberg design triage meeting.

We agreed to close it in favor of all the parallel work and exploration happening for Full Site Editing.

[earnjam]

Wish that discussion occurred in text format and not on a recorded video call. Going to be difficult to track down later to understand the reasoning. 🙁

The reason I say this is I was about to go refresh a stale PR I've had open since before WP 5.0 launched related to A11y and private publishing that is also somewhat tied into this discussion. (#12023)

I'd like to know whether it's something I should bother working on or not, but I have no idea without trying to find the video link later after it's published on the Design P2, then watching the whole meeting for the relevant discussion.

[mapk]

@earnjam, your concern makes a lot of sense. The discussion happened more in video to help educate future triage leaders on how to conduct triage sessions. Definitely noted that if these happen in video again, we need to transcribe the conversations, or at the very least be more detailed in our comments when responding to issues. Thank you for bringing this up.

Back to topic... The top toolbar is going through some changes in response to the full site editing experience, so figuring out "how" and "where" to share the post status might need to be postponed until we get that toolbar solid. If it's just a matter of working a better flow into the mix, as in your other PR, let's do it.

My suggestion is if you're planning to update the other PR, please do. I know that one has some oddities that need testing as well. Let me know when it's ready for another review! 😄