Gutenberg: New Block: Post Date

[mapk]

As indicated in #15623, there will be a suite of Post blocks that make up the Post template.

This is the Post Date block.

Features

• Support for date formatting.
• Allow editing by opening a calendar.

Mockups

Questions

• Should the "time" toggle exist separate from the "format" dropdown, or should it be included in the dropdown?
• Should the format be included in the block toolbar as a primary action?

[epiqueras]

Should the "time" toggle exist separate from the "format" dropdown, or should it be included in the dropdown?

I think it's cleaner to keep it together with the format.

Should the format be included in the block toolbar as a primary action?

Yes, I think this should be in the toolbar and that the calendar should open when clicking on the date in the block itself. This aligns better with the philosophy of direct manipulation.

[mapk]

Look at me just defaulting to the sidebar! Thanks for pulling me back, @epiqueras.

Here's are some revised mockups.

Date selection

Date and time format

Notes

• I've not added all the date and time formats, but just prepared something visual.
• I'm not sure the "Date and time format" popover should include a heading as my mockup shows because I don't normally see this pattern in other areas, or haven't noticed.
• Is an "Edit" pencil icon good for this interaction? I _think_ so.

[epiqueras]

That looks so much better! Nice work.

I'm not sure the "Date and time format" popover should include a heading as my mockup shows because I don't normally see this pattern in other areas, or haven't noticed.

Yeah, we can drop it.

Is an "Edit" pencil icon good for this interaction? I think so.

I would like to see something more descriptive here. Maybe a sketch of 2 different formats with a slash between them?

[mapk]

Here's a mockup using the "M/D/Y" as the icon for date format. I've also removed the heading from the popover and added an option with the time too so we might see what that looks like.

However, I don't think the M/D/Y are good for i18n.

[epiqueras]

How about a calendar with a clock and some sort of edit indicator?

[mapk]

Here's a couple icon variations. We need to be careful not to add too much to an icon for the sake of clarity. I fiddled a bit with combining a pencil and calendar.

[epiqueras]

I like the first one the most.

[epiqueras]

The calendar is less clear on the second one and the third one blurs the
pencil.

[mcsf]

It would be good to also recognise and support the site's global date format, per the setting on wp-admin/options-general.php, including honouring whatever custom value it may have:

[epiqueras]

It should default to that.

[richtabor]

Here's a couple icon variations. We need to be careful not to add too much to an icon for the sake of clarity. I fiddled a bit with combining a pencil and calendar.

What if we used the word "Format", similar to how the Image block (and relative blocks) employ "Replace" instead of an icon?

[epiqueras]

Localization can break the layout with long words.

[richtabor]

Localization can break the layout with long words.

What's the solution for the Image block then, in regards to i18n with "Replace"?

[epiqueras]

There isn't one. We could make an icon with a thumbnail and a replacement arrow.

[shaunandrews]

I noticed this issues has a lot of chatter around editing the date itself. This brings up an interesting question; Are you editing the post itself? If so this will bring up some _interesting_ complexities around saving and publishing changes.

Instead, I'd suggest that this Block (and the other related Post blocks) are more about display content defined elsewhere. Options on these blocks should allow users to adjust display properties (color, font, size, date format, alignment, etc) but the content itself should _not_ be editable.

In the context of the larger Post block, the post_id would be defined by the parent block. But in scenarios where these _post-related_ blocks (like this Post Date block) we'll need to add some UI for selected a post_id in the setup state, and (maybe) in the toolbar. Here's a quick mockup:

Once the post is selected, the option could be accessible from the sidebar:

--

I'm a fan of using a labelled dropdown for the formatting options. Something like this is what I would expect:

Combining the day and time formatting would also mean we wouldn't need the "Show time" switch in the sidebar.

[epiqueras]

Instead, I'd suggest that this Block (and the other related Post blocks) are more about display content defined elsewhere. Options on these blocks should allow users to adjust display properties (color, font, size, date format, alignment, etc) but the content itself should not be editable.

I think that argument can be made for things like the date because of scheduling. But directly manipulating the excerpt is a lot more intuitive. The same can be said of the featured image, for example.

But in scenarios where these post-related blocks (like this Post Date block) we'll need to add some UI for selected a post_id in the setup state, and (maybe) in the toolbar. Here's a quick mockup:

Replicating this functionality in every post field is repetitive. You would wrap it in a post block that already has a post selector.

Combining the day and time formatting would also mean we wouldn't need the "Show time" switch in the sidebar.

Yes, we are already doing that.

[shaunandrews]

But directly manipulating the excerpt is a lot more intuitive. The same can be said of the featured image, for example.

Hmmm, I don't know. Unless the contents of the excerpt is isolated (and not actually editing the excerpt data for the post in the DB), I could see there being confusion around editing a post's data and not understanding that it will change it everywhere. Also, there'd still be an issue around saving post data — would the data be saved immediately? When you published the post/page that contains the customized block? What if the page containing this block is scheduled, would we only update the post data when the page is published?

Replicating this functionality in every post field is repetitive. You would wrap it in a post block that already has a post selector.

But what if these post-related blocks are used _outside_ of a post block? Or, is that not something we'd want, or would consider useful?

[epiqueras]

Hmmm, I don't know. Unless the contents of the excerpt is isolated (and not actually editing the excerpt data for the post in the DB), I could see there being confusion around editing a post's data and not understanding that it will change it everywhere. Also, there'd still be an issue around saving post data — would the data be saved immediately? When you published the post/page that contains the customized block? What if the page containing this block is scheduled, would we only update the post data when the page is published?

This is all related to global change saving. See the discussions on #18029.

But what if these post-related blocks are used outside of a post block? Or, is that not something we'd want, or would consider useful?

They will inherit the root post ID if any, otherwise they will show a placeholder. This approach optimizes for being able to easily move these blocks between post and query blocks and reuse layout pieces across different contexts without having to deal with post-selection at multiple levels.