You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Here's how the Date field looks in the Pages data view:
It's not clear which date is being referred to. Specifically; is it the publish date, the modified date, or something else? This detail is clarified in wp-admin with a preceding label:
I suppose the simplest way to tackle this would be to mimic wp-admin and add a prefix. Are there other ways, could/should publish date and modified date be split into separate fields?
This'll take some finessing, but it might be hard to not have to need two lines of text there. It might be good to gather a bit of comparison material across other apps that have similar formats, see what standards there are.
could/should publish date and modified date be split into separate fields
I think this could be worth discussing. Filtering by publish date (a legitimate use case) is very different to filtering by modified date (still legitimate, but probably less common?).
You'd only ever see Published or Modified, in the existing pages, right?
Also "Scheduled".
make an effort to ensure the dates line up vertically
Yeah that's a bit tricky. We might have to choose between vertically aligned dates or separate lines.
Another option could be to use a 'human friendly' date format e.g. "Published 30 minutes ago" which might mitigate the alignment issue? The actual timestamp could appear in a tooltip on hover if required.
I have no strong opinion about this, but if we feel like both modified and published dates have value, we should probably have them as separate fields. That would probably help with the filtering (when we have date filters).
Additionally if we render both dates in a single field (two lines), I guess in some of them we'll only have one and I'm not sure if this affects the design for any reason. An example is draft posts will always have only modified date.
I'd tend to reach parity first, and then expand beyond that when we know it's necessary. This is a cat that's hard to put back in the bag. Easy to expand, hard to contract.
@ntsekouras no, because we need to capture modified dates for drafts. So for now it means adding a prefix to the field value. I added a screenshot to the OP.
Activity
jasmussen commentedon Apr 5, 2024
This'll take some finessing, but it might be hard to not have to need two lines of text there. It might be good to gather a bit of comparison material across other apps that have similar formats, see what standards there are.
jameskoster commentedon Apr 5, 2024
I don't know that it needs to involve two lines. The prefix could be a single word:
Modified: April 5, 2024, 09:55,Published: April 5, 2024, 09:55.jameskoster commentedon Apr 5, 2024
That said...
I think this could be worth discussing. Filtering by publish date (a legitimate use case) is very different to filtering by modified date (still legitimate, but probably less common?).
jasmussen commentedon Apr 5, 2024
You'd only ever see Published or Modified, in the existing pages, right? That would simplify things, and maintain the value as well as the density.
Building on your suggestion but using the existing date format, this isn't bad:
Mainly wondering, could we/should we make an effort to ensure the dates line up vertically, even if the prefix varies in width?
jameskoster commentedon Apr 5, 2024
Also "Scheduled".
Yeah that's a bit tricky. We might have to choose between vertically aligned dates or separate lines.
Another option could be to use a 'human friendly' date format e.g. "Published 30 minutes ago" which might mitigate the alignment issue? The actual timestamp could appear in a tooltip on hover if required.
ntsekouras commentedon Apr 5, 2024
I have no strong opinion about this, but if we feel like both modified and published dates have value, we should probably have them as separate fields. That would probably help with the filtering (when we have date filters).
Additionally if we render both dates in a single field (two lines), I guess in some of them we'll only have one and I'm not sure if this affects the design for any reason. An example is draft posts will always have only modified date.
jameskoster commentedon Apr 5, 2024
I suppose the usefulness of separate fields is:
Seemingly the modified date is already tracked somehow as it appears in the Inspector:
So I guess it wouldn't be a big lift to make it a field?
I think that's okay given the explicit labels. It would be strange for a draft post to have a publish date.
jasmussen commentedon Apr 5, 2024
I'd tend to reach parity first, and then expand beyond that when we know it's necessary. This is a cat that's hard to put back in the bag. Easy to expand, hard to contract.
jameskoster commentedon Apr 5, 2024
Agreed. For now let's mimic wp-admin, IE add the prefix.
We can follow-up to discuss in more detail the addition of a separate 'modified date' field.
ntsekouras commentedon Apr 22, 2024
Does that mean just change the label from
datetopublished date, or something different?jameskoster commentedon Apr 23, 2024
@ntsekouras no, because we need to capture modified dates for drafts. So for now it means adding a prefix to the field value. I added a screenshot to the OP.
oandregal commentedon May 16, 2024
I'm giving this one a shot.
oandregal commentedon May 16, 2024
PR at #61709