Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New Block: Post Date #19697

Closed
mapk opened this issue Jan 16, 2020 · 19 comments · Fixed by #19857
Closed

New Block: Post Date #19697

mapk opened this issue Jan 16, 2020 · 19 comments · Fixed by #19857
Assignees
Labels
Customization Issues related to Phase 2: Customization efforts Needs Design Feedback Needs general design feedback. New Block Suggestion for a new block [Status] In Progress Tracking issues with work in progress

Comments

@mapk
Copy link
Contributor

mapk commented Jan 16, 2020

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

Screen Shot 2020-01-15 at 6 32 43 PM

Screen Shot 2020-01-15 at 6 32 28 PM

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?
@mapk mapk added Customization Issues related to Phase 2: Customization efforts New Block Suggestion for a new block labels Jan 16, 2020
@mapk mapk changed the title New Block: Post Date block New Block: Post Date Jan 16, 2020
@epiqueras
Copy link
Contributor

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 mapk added the Needs Design Feedback Needs general design feedback. label Jan 16, 2020
@mapk
Copy link
Contributor Author

mapk commented Jan 16, 2020

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

Here's are some revised mockups.

Date selection

Screen Shot 2020-01-16 at 9 34 05 AM

Date and time format

Screen Shot 2020-01-16 at 10 04 29 AM

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
Copy link
Contributor

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
Copy link
Contributor Author

mapk commented Jan 17, 2020

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.

Screen Shot 2020-01-16 at 4 08 49 PM

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

@epiqueras
Copy link
Contributor

epiqueras commented Jan 17, 2020 via email

@mapk
Copy link
Contributor Author

mapk commented Jan 17, 2020

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.

icon

@epiqueras
Copy link
Contributor

epiqueras commented Jan 17, 2020 via email

@epiqueras
Copy link
Contributor

epiqueras commented Jan 17, 2020 via email

@mcsf
Copy link
Contributor

mcsf commented Jan 17, 2020

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:

Captura de ecrã 2020-01-17, às 11 54 45

@epiqueras
Copy link
Contributor

It should default to that.

@github-actions github-actions bot added the [Status] In Progress Tracking issues with work in progress label Jan 24, 2020
@richtabor
Copy link
Member

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?

format

@epiqueras
Copy link
Contributor

Localization can break the layout with long words.

@richtabor
Copy link
Member

Localization can break the layout with long words.

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

@epiqueras
Copy link
Contributor

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

@shaunandrews
Copy link
Contributor

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:

image

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

image

--

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

image

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

@epiqueras
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

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.

@MikeWhelan
Copy link

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:

Captura de ecrã 2020-01-17, às 11 54 45

It's been two years since this announcement was made. When will it be possible to use a date block that defaults to site's global format? In my case, I just want to show the year ( 'Y' ), but that option is not available, even though it is specified in my global options.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Customization Issues related to Phase 2: Customization efforts Needs Design Feedback Needs general design feedback. New Block Suggestion for a new block [Status] In Progress Tracking issues with work in progress
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants