Post Summary Panel: Change the "Publish" label to a more accurate label

[t-hamano]

What problem does this address?

As I understand it, the word "Publish" is only used as a verb. Therefore, I think it is appropriate to leave the blue button in the upper right as "Publish".

On the other hand, the same word "Publish" is used in the summary panel. It feels strange that this label is the only one that is a verb, while all the other labels are nouns.

Perhaps the word "Publish" can cover both the meaning of a verb and a noun in English, but this translatable string does not have any additional context.

Therefore, it is not possible to apply a context-sensitive translation in locales other than English.

What is your proposed solution?

I would like to suggest using a more accurate label other than "Publish" in the summary panel.

If we want to follow the label in the classic editor, "Published on" might be good.

Alternatively, I would like to suggest the text "Published date".

cc @WordPress/gutenberg-design @afercia

[afercia]

@t-hamano good point. I'd agree the verb sounds a bit out of place there. In a way this was also noted in an user session long time ago, see #470 (comment)

"Publish" is weird to me, it seems like an action but it's just text ...

Couple more considerations:

The default date/time value when creating a new post is Immediately, which is likely the reason why this visual label was changed to Publish. The new wording should complement well with Immediately.

The verb Publish is used also as the title of the calendar popover. I'd think it could be improved there as well. Scrsenshot:

[jameskoster]

Date information is a bit messy. In data views there is a "Date" field which conditionally displays one of the following:

• Last modified date for unpublished posts
• Exact publish date for published posts

Then there's this "Publish" control in the Inspector, which communicates just the publish date for both published and unpublished posts.

Would it make sense to tidy this up a bit? For instance we might store separately the publish date and the modified date. This would be handy in data views because it would allow you to sort with more granularity, e.g. view published posts sorted by last modified. This could also inform the labelling in the Inspector; with two such fields you might expect them to be named "Modified date" and "Publish date". So in the Inspector we'd simply update "Publish" to "Publish date".

Slightly tangential, but I would also pose that the "Publish date" control is not shown at all for draft posts, which would circumvent the awkward "Publish date: Immediately" language. "Publish date" only really makes sense when the post is scheduled, or already published. Otherwise it seems reasonable to assume that a publish action would result in an immediate publish date.

[afercia]

Worth noting the Publish date popover does have an aria-label="Change publish date".

The popover doesn't have an ARIA role though so this is just exposed as a labeled generic element. Some screen readers will announce it as group, which is arguably correct. Other popovers are labeled as well.

[afercia]

A couple more considerations:

The adverb 'immediately'
I don't like that it is not used consistently. In the Panel it's 'immediately' but in the calendar popover is 'Now'. This inconsistency doesn't help users to immediately understand what 'Now' does. I'd argue that whether it's 'immediately' or 'Now', the UI should use the same term everywhere. Screenshot:

The publish date/time label
I'm not saying that it is necessarily better but I'd like to remind everyone that in Classic editor the visual label for the publish date/time is dynamic and it changes depending whether the selected date / time is in the past, in the future or 'now':

[t-hamano]

I'm not saying that it is necessarily better but I'd like to remind everyone that in Classic editor the visual label for the publish date/time is dynamic and it changes depending whether the selected date / time is in the past, in the future or 'now':

This is interesting. Would it make sense to apply this dynamic labeling to the block editor as well?

but in the calendar popover is 'Now'. This inconsistency doesn't help users to immediately understand what 'Now' does.

Wouldn't it be easier to understand what "Now" means by changing the title of the popover to "Publish date"?

Either way, when using the term "Publish" as a label, I believe some context is needed, for example:

_x( 'Publish', 'as label' );

[afercia]

Wouldn't it be easier to understand what "Now" means by changing the title of the popover to "Publish date"?

That would help.
To me, one of the most weird things is when starting from a publish date / time:

and then I click 'Now' in the Popover, the date / time changes to 'Immediately':

as a user, I would expect it to change to 'Now' because, well, I just clicked a button that says 'Now'.
Or, the other way around: they should both be labeled 'Immediately'.

Either way, when using the term "Publish" as a label, I believe some context is needed,

Good point, the _x() translation function would help.

[jameskoster]

Now that Status is a dedicated, editable field I'm curious whether we need to display the publish date for unpublished pages.

Setting a publish date for a draft feels a bit strange because it means the page is no longer a draft; it's scheduled. It's very easy for these two fields to end up in an incompatible state, and there's a lot of code behind the scenes to avoid that happening.

I tend to lean toward intrinsically linking the status & publish date control, something roughly like this:

This feels a bit more natural to use, and avoids the aforementioned incompatibilities. In the short term we might try conditionally showing/hiding the "Publish" row in the Summary panel.

[t-hamano]

When I write a personal blog, I sometimes decide the publish date I want in advance and set the status to Draft until the article is completed. I think there are many other cases where the publish date is decided in advance, such as WordPress release announcement articles.

For this reason, I prefer to have the publication date always displayed.

[jameskoster]

Thanks for sharing that context, I can see it's a workflow that makes sense in certain situations.

Changing the "Publish" to "Publish date" and aligning the "Now" and "Immediately" labels seems like a good change to me.

It's probably separate but I don't love the UI/UX for the "Now" button. The interaction with the calendar isn't immediately obvious... I wonder if it should be more connected, and use a more conventional control:

[t-hamano]

I wonder if it should be more connected, and use a more conventional control:

This is a great idea and I think it could be pursued in parallel with this issue 👍

[afercia]

I don't love the UI/UX for the "Now" button. The interaction with the calendar isn't immediately obvious... I wonder if it should be more connected, and use a more conventional control:

Yes I'd totally agree. The only concern is that if the default is 'Now', to switch to the calendar and set a date I'd have to click one more time. We're also assuming that 'Now' is the most used choice, while it isn't necessarily true. How about let users decide whether to 'stick' to the 'Now' option or to the 'Choose a date' one?

[jameskoster]

@afercia you mean make the default selection an editor preference, or a site setting? That seems reasonable, but perhaps a separate endeavour?

@t-hamano do you think this one is ready for dev?

[afercia]

@afercia you mean make the default selection an editor preference, or a site setting? That seems reasonable, but perhaps a separate endeavour?

@jameskoster definitely can be split in a separate issue for broader discussion. I'd tend to think each user may have a personal preference or editorial flow where one of the 'Now' or 'Choose a date' options would be the most used one. As such, I'd tend to think it should be a user preference for the editor. Also, I'd tend to think the control to set the preference should be 'in place' e.g. something like 'Make this the default choice'.