Improve Tier 3 reports so we need to use Tier 2 less

[cjyabraham]

To reduce the need for the web team to be involved in tier 2 report production, turn the key design elements in tier 2 reports into Gutenberg blocks or block patterns so that they can be set up by any editor, similar to a case study.

The report should have the full list of regular page styles exposed, such as the gradient-down and gradient-up styles.

Blocks/patterns needed (based off the CTO Summit report and transparency report):

• hero
• sidebar stats (shown to the right of the opening para)
• section headings (configurable color for underline)
• sliding gallery
• thank you section
• jump-to TOC style buttons (should accommodate up to 9 buttons?)

[thetwopct]

Some early thoughts on this:

• I'm not overly sure how possible this is to do - for example the hero has changed quite wildly between each report we have done so far and needs to consider responsive views. The CTO Summit report is the simplest type of hero we have done (simple background picture with text overlay), so there may be design restrictions we need to impose. Even then, things like titles or logos change, and this affects the whole layout. And then at the last minute (as reports are often on tight deadlines) if the layout we can do is not good enough we would need to scramble to custom code.

• We could find ourselves in a tricky situation where we have some advanced custom report blocks that we want to use on more reports, but then they cannot be easily used in pure HTML reports (you cannot embed blocks AFAIK in to HTML like you could, say, a shortcode).

• We should restructure our gulp build and the way we enqueue style sheets in the theme to load styles based on block usage / template / CPT. This will reduce the size of styles loaded on every page. Creating all new blocks but loading them on every page will create unnecessary overhead.

• All these custom blocks would be easier/quicker to build by using Advanced Custom Fields framework. I don't mind building Gutenberg implementations, but I know that ACF would allow for a simpler user interfaces for advanced blocks (i.e. ACF focuses on input fields, where as Gutenberg is typically much more visual) and quicker build times (i.e. building the slider with ACF is under an hours work, with Gutenberg its probably 2-3 days plus ongoing maintenance)

• In the short term I can experiment with some block patterns and see if they help fill the gap rather than creating custom blocks (but my guess is that the complexity of many of our designs will prevent many block patterns working well)

[cjyabraham]

Makes sense. Perhaps we wait a bit longer to see if our upcoming reports can stabilize around a consistent set of style patterns.

[cjyabraham]

Sounds like we should move forward on this. First step is to discuss with G on a Marketing call to see if he can buy in to the project and provide a set of canonical styles for tier 2 blocks...

[cjyabraham]

@KTan1226 has asked that we pause on this task until we have Thabang here to weigh in on the discussion

[KTan1226]

Thanks again for the discussion on this! We decided to test out creating the blocks for Project Journey Reports first. @thetwopct will take the lead on mapping out timing and working on this for the next PJ Report (later in October).

Additionally, we will be reviewing the tiering system and timelines for review next week. Kristi + @Charley-Mann will take the first stab at updating this doc and then we will review as a team next week in our MP call.

[GarethAcidWorks]

Hi all, just catching up on this with notes from last nights call.

My primary thoughts are:

1) We will often have, and will need to be able to execute unique content & data when something comes along. If an event has a new topic of e.g data, and we didn't do that in the past, we will have to create a solution for that. Therefore a template will never be all answering.

2) Also mentioned on the call, the quality of the design and build of our reports now is gold standard. We no longer need to fine tune sizing, titles, spacing, font styles etc... all of this is well tested and executed. Meaning we can much more rapidly create new reports (Speaking on before of the design team, we now has a 50 - 75% reduction in effort because of this).

So my thoughts are... this is now our platform to retreat at high standard.

3) On the topic of blocking / building more CMS style functionality so others can enter data... I believe only a co lo report would make sense here. But they will still need our help for colour & logo application. That is if we want to ensure the standard of all our reports stays 'gold'.

4) Regarding discussion of tears, let's keep this simple, and we now have a fairly clear landscape and set of deployed reports to support this approach: Tier 1 - Annual Reports, Transparency style reports (With downloadable PDF) Tier 2 - Project Journey style reports (No PDF) Tier 3 - Co Lo style reports (No PDF, identical content)

In summary: • I believe we should execute to at high standard based on the foundation we already have established. • Be realistic about the likelihood of bespoke requests and avoid trying to templatize everything

[GarethAcidWorks]

Thought...

If use Co Lo reports as a thought experiment...

Would it not be better to simply engage a lower cost developer to churn these out. (Who we could also use to support on other tasks).

Rather than building a system to events folk can do it themselves?

[thetwopct]

Thanks again for the discussion on this! We decided to test out creating the blocks for Project Journey Reports first. @thetwopct will take the lead on mapping out timing and working on this for the next PJ Report (later in October).

Additionally, we will be reviewing the tiering system and timelines for review next week. Kristi + @Charley-Mann will take the first stab at updating this doc and then we will review as a team next week in our MP call.

While working on the mapping out of PJR build as well as reading comments in this thread I wanted to ensure the project and scope was fully understood as they are quite a few nuances, so I took at stab at rewriting the CNCF Web Delivery Report myself. I hope that's OK. This includes issues/findings since tiers were introduced, a proposed revised tier structure, and adds in 5 decisions required to move forward, as well as a breakdown of what blocks/styles I need to build (I didn't think after our last meeting sign off was given for me to actually do that yet, just cost it up). The document is open for comments. Would be great to discuss in tomorrows marketing pod.

[thetwopct]

Hey @cjyabraham @Charley-Mann @GarethAcidWorks + @ThabangMash, @KTan1226 asked me to specifically share with you my updated document on how we can deliver web reports (also above). Here's the link to the document and it's open for comment. Please leave comments before Thursday W+D Marketing Pod (6th October) so we can then finalise in the meeting and move forward with it. Thank you! 🙏

[thetwopct]

Hey @cjyabraham @Charley-Mann @GarethAcidWorks + @ThabangMash, @KTan1226 asked me to specifically share with you my updated document on how we can deliver web reports (also above). Here's the link to the document and it's open for comment.

Hey y'all, thanks for marketing pod call and sorry we didn't get to cover everything before our time was up. Please do comment on the "Decisions to be made" in the Document with a Yay/Nay or approval where relevant so we can move forward as fast as possible, the quicker we make decisions and get approval the quicker we can start work and avoid a logjam in December! Thanks 🙏

[thetwopct]

Outcomes:

• PDFs should be decoupled from Tiers and optional for any Tier
• Approval for @thetwopct to begin building blocks for use in OpenTelemetry PJR report
• Old reports will be preserved as they are

I have already started building the blocks based on Argo PJR

[KTan1226]

+1 - Thank you, James

[thetwopct]

This is currently being blocked by an asset loading issue - https://github.com/cncf/cncf.io/issues/619 - a fix is in progress.

[KTan1226]

Thanks for the update!

[thetwopct]

Marking this as done now, we have a really good base of blocks that can be used to generate great looking reports without much design input.

For example, K8S PJR is purely block based - https://www.cncf.io/reports/kubernetes-project-journey-report/

More custom reports (Tier 1 / Tier 2) still require custom HTML approach depending on their complexity.