Content Section: Grid

[wwwwwlwwwww]

Description

Please see parent issue #708 for additional information/context before proceeding.

• Grid of Content Blocks. This needs to arrange an indeterminate number of content blocks in grid form. This should be a margined content section. The parameters are:
  • An ordered list of content blocks to be displayed
  • Column bound or row bound?
  • The number of rows/cols (it'll be one or the other depending on whether it's row-bound or column bound)
  • Order - three options: left to right, top to bottom, or random
  • Banner or Margined (see Create content section holders for website #708 for meaning of this)

Concrete Use Case: #771

Next steps:

• Weston to make concrete use case examples
• Triage

Front end feature screenshots

Code of Conduct

• I agree to follow this project's Code of Conduct

[coderbyheart]

Can you provide a concrete use case and example for the content blocks? This would help the implementing developer to see how this feature is going to be used. Because in practice, we have this feature already, because CSS grids and Tailwind offer it.

[wwwwwlwwwww]

Absolutely! I didn't have time to do much on the website today, but this week I should be able to get a more concrete use case or two up.

[wwwwwlwwwww]

Sorry for the delay in getting this done. I think issue #771 should be a good use case for how the ideas of content blocks, content sections, and pages come together. Some of these concepts are more involved on the CMS side than in code; for example, if grid functionality can be achieved super easily and repeatably on the code side through CSS grids or Tailwind, that's great. It'll be more a matter of setting it up so that when someone in Forestry creates a content section with attributes margined, column-bound, 2 columns, and a set of content blocks within it, that can be easily translated to a page by coders using CSS/Tailwinds.

The overall vision of what we're setting up is this: someone from the team who's not super knowledgeable about tech can go into Forestry and essentially build a (more or less) static page in Forestry: they can specify things like the URL slug and page title, they can create different section holders for content, and then they can input the actual content they want on the site. For example, in #771, I added a couple photos, some text, etc. Once this has been done, a Github issue can be created to actually finalise these fields into a finished page and devs (junior or senior) can easily put it together based on the information in the CMS + the existing work that's been done to create the functionality for content sections and content blocks in the code. This way we can quickly produce pages when we need them and things are more editable because there's less coding, plus it can free up more senior devs to focus time on solving more complicated problems beyond front end page creation.

Does this make sense? I took some computer science classes in Java and C# (primarily) a few years ago and have some experience with R, but I'm definitely far from even junior dev level, so let me know if any of this sounds technically nonsensical!

[coderbyheart]

In my experience with DA there has not been the need for this kind of workflow in the past. What worked was getting all the finalized content collected in Drive / Notion and then have a developer implement it. I am sceptical whether the workflow you outline will be used regularly and to me it sounds much like premature optimization: we would be the building the infrastructure to support future content assuming that it will materialize.

I'd rather build the infrastructure once it turns out that the process we have today (collect content in Drive / Notion / GitHub issues, then add the page to Gatsby) is not fast enough. And I don't see that we have any problems today to getting the content we need online, when we need it.

Implementing a generic CMS is 10x more expensive and much less flexible, keep that in mind.

But these are just my 2 cents. I guess @jtfairbank can provide a bit more context to the vision here.

[jtfairbank]

Hey @coderbyheart! I think we're trying to achieve a middleground here, in order to negotiate a separation of concerns between content contributors and code contributors. The goal is to achieve the following workflow:

1. A data stream is created by content contributors. ex: needs assessment data server, shipment data pipeline, or forestry for more "document" based data
2. Code contributors & content contributors agree on an import data format that the landing site consumes. ex: needs assessment API, shipment data json format, standard forestry templates / partials
3. This now allows each side of a data stream to focus on what they are able to do best:
   • Content contributors keep the stream flowing, and work on creating new data streams with the components that are currently available.
   • Code contributors focus on building new components that can consume that stream of data and be shown wherever needed on the site.
4. This in turn makes it easier for:
   • Content contributors to update existing parts of the site without needing a dev involved.
   • Devs to add new parts of the site knowing that the content they consume will be kept up to date.

That's my thought process anyways. I think the goal is to keep this layer very lightweight: essentially exposing a few flex / grid toggles to forestry and having a few standard components to use when creating a page. We're also not applying it everywhere, just when more page-based custom content is needed.

Definitely welcome feedback on this approach! @hola-soy-milk might be an interesting one to discuss on the stream as well, ask the audience?