Closed noeltock closed 2 years ago
Hey @roborourke , thanks for offering to support on these pieces, from the original design, open to ideas:
width = 160
, I propose variable widths on date range selected:
100
120
150
↑ 2%
or ↓ 2%
, probably makes sense to stick with rounded integers. Is that too far out of scope, or hard to do, maybe that's why it was left out? 17D OLD
, if under 1 day 1H OLD
, etc.PARENT NAME
if one existsLet me know if there are any questions, don't have anything to push up from my branch.. cheers!
The relative date display in the format you have on the mockup is going to be a pain to implement, this is using moment.js's built-in fromNow()
method which is internationalised through WP. Happy with that?
Not sure what happened to the original comparison % for 7D and 30Ds, along the lines of ↑ 2% or ↓ 2%, probably makes sense to stick with rounded integers. Is that too far out of scope, or hard to do, maybe that's why it was left out?
I think it was descoped, but to be honest to fetch this data is going to be quite an expensive query. I think I might have to split it out into per post queries. Individually they should be fast, but showing 50 posts per page or whtever it is by default... that's a lot of queries..
Progress so far:
There's not much to indicate what the parent page link is besides colour, but especially for XBs it's useful to have it there. Let me know if you have any further thoughts.
This is the contrast check output for the small grey text on the gray background https://webaim.org/resources/contrastchecker/?fcolor=7B7B7B&bcolor=F5F6F8
It will pass AA if the grey text is #707070
The relative date display in the format you have on the mockup is going to be a pain to implement, this is using moment.js's built-in fromNow() method which is internationalised through WP. Happy with that?
Yep! I'm assuming you saw https://github.com/moment/moment/issues/2781#issuecomment-160739129 ?
There's not much to indicate what the parent page link is besides colour, but especially for XBs it's useful to have it there. Let me know if you have any further thoughts.
With the shift/movement around global blocks as the common denominator, does it still make sense to show an arbitrary page in which an XB is located? Or does it show only show if the XB has a single child page (in the global block/XB world, I guess blocks don't have pages as parents, but as children, at least conceptually)? Thoughts?
With the shift/movement around global blocks as the common denominator, does it still make sense to show an arbitrary page in which an XB is located? Or does it show only show if the XB has a single child page (in the global block/XB world, I guess blocks don't have pages as parents, but as children, at least conceptually)? Thoughts?
From a technical standpoint an XB can't exist in isolation, it has to be created somewhere whether that's a global block, post, page etc... so it's not arbitrary in that sense. I didn't think it made much sense initially, especially with things like A/B tests that you could create the block but not be gathering any data for it. We can maybe revisit that a bit with some work, e.g. a "waiting for data" status to know if it's used somewhere.
If an XB is on a post or page it'll show that as the parent, for an XB on a global block the global block will show as the parent right now. It was too complicated to build or modify the reusable blocks interface at the time I originally coded them.
Regarding XBs/Global blocks as having child pages - that makes sense in terms of there being a one-to-many relationship but conceptually it's a bit different. They might be on template parts like header / footer, or broadcasts, or whatever. We'd need to think of all of those elements as content pieces. I'm not really sure if people will really get into that mode of thinking or look at it in that way with WP, even in light of FSE. Some stuff will be in the db, some will be in code templates.
There was a question early on about whether we should require XBs to be only allowed in reusable blocks but we decided they should be immediately usable. If we can figure out a way to make it as simple to start an XB as it is now without explicitly creating a global block first we could try and see if it's any easier now.
Work in progress