Provide feedback on Drupal CMS content strategy v1.0

Seeing the community come together to establish and collaborate on Drupal CMS's content model is inspiring.

This initial content model will set the foundation for all content models in the Drupal community. I have been working on the Schema.org Blueprints module → for a few years and am focusing on building standardized content models based on Schema.org. Based on my experience, I have a few thoughts and suggestions.

It helps to track all the decisions using Architecture Decision Records (ADRs). Drupal's Experience Builder has adopted them. 📌 Record Architecture Decisions — to scale to many people + many timezones Fixed The Content strategy for v1 → document already includes many initial decisions.

In the Schema.org Blueprints module, I use a lightweight​​ version of ADRs, which are tracked in a single document. Anyone can read the ADR document to understand the what and why behind decisions around code, content models, and more.

I suggest documenting some decisions/suggestions/details below for Drupal CMS's content model.

• Field naming conventions
• Field label conventions
• Field descriptions
• Max lengths
• Require fields
• Field order
• Allowed values

Of course, I have opinions about all these decisions. Some of the above decisions still need to be documented in the Schema.org Blueprint module. The most significant decision I would propose is that Drupal CMS use Schema.org type and property names whenever possible to ensure internationalization and standardization.

For example, we could use https://schema.org/givenName and https://schema.org/familyName for the 'First name' and 'Last name' field names (i.e., field_given_name and field_family_name). An ADR could allow field names to differ from the label when a field name is more appropriate for APIs and internationalization.

Another good example is to use https://schema.org/keywords with 'News article' instead of tags. Using keywords also aligns with meta tags.

Another specific example is https://schema.org/Event, which has an https://schema.org/eventSchedule property perfect for recurring events and an https://schema.org/EventStatusType enumeration for tracking the https://schema.org/eventStatus.

Lastly, Schema.org's type hierarchy (https://schema.org/docs/full.html) suggests that Drupal CMS should include a https://schema.org/Place content type.

In my experience, using https://Schema.org works for 80% of most enterprise content model requirements, and occasionally, you must add additional non-Schema.org types and fields. For Drupal CMS, a baseline starting point, using https://Schema.org could work for 100% of the content types and fields.

May I suggest https://github.com/acquia/drupal-spec-tool as a way to define the content model?

The google sheet can be copied and then we can remove the Acquia CMS Community starter kit fields, content types etc and fill it in with the Drupal CMS ones. Once all content types, fields (with names and types), menus, etc are added we will end up with a living document that gives us an immediate bird's eye view of the Drupal CMS content model that anyone can then take and implement.

The current content strategy currently calls out only content types. We should also define the taxonomies (e.g Tags) that will ship with Drupal CMS as well as any menus (e.g Main Navigation, Footer, Social links) and media types (Image, Document, Video (remote?)) and call them out specifically as these entities could have their own fields that we need to create as well. I assume we will avoid using the image and file fields and we will instead use media entities which should also be called out.

Additional things to consider for the content model and be added to the spec tool:
- Image styles (since we have fields for feature images it would make sense to define some out of the box image styles as well)
- Views for listing content such as events and blogs (probably provided by their respective recipes)
- User roles (who will be able to edit what)

Do we want to add relationships between the content types? For example, the article, blog, project, case study content types could have an "author" field that references the "person profile" content type.

Is the location field on the event content type an address field, or a reference field to a location content type (in which case we also need to define that).

Some fields such as "body" and "description" seem like they would be rich text fields. These should be defined with the appropriate text formats as well. Which leads me to the Full HTML text format. This could be considered a security risk and ideally we should disable it or completely remove it.

To improve usability and consistency, as well as driving broader adoption I suggest simplifying the data model.

Simplifying the model

All content types (nodes) could be structured around the following core fields (specific naming can be finalized later):

1. Title
2. Description
3. Image
4. Tags
5. Content

In this structure, Title, Description, Image, and Tags are standard fields, while Content would be a reference field for display components (such as block types) that visually construct each page.

A streamlined data model allows for broader adoption and flexibility, enabling users to build custom structures as needed.

When introducing new content types, additional fields should only be added to reflect essential differences.

For example:

1. A News Page type could include a Date field.
2. An Event Page might add both Date and Location fields.

Display Components

Display components refer to separate entities (e.g., block types) that manage their own data models and are independently installable, with rendering managed by tools like Single Directory Components (SDC).

Basic components might include:

1. Text
2. Image
3. Page reference

Additionally, components such as

1. Headline,
2. Slideshow,
3. Gallery, and
4. Views Reference

provide users the flexibility to select or create only the components required for their use cases.

Differentiating Content Types (e.g., Press Release vs. Blog Post)

Differentiation between content types, such as Press Release and Blog Posts, could be managed through Tags, with display components handling visual differences.

For instance, a Press Release might include:

1. Title
2. Date
3. Summary
4. Text
5. Quote
6. Media contact

Whereas a Blog Posts might feature:

1. Title
2. Date
3. Author
4. Reading time
5. TL;DR
6. Text
7. Related blog posts

Structuring Pages (e.g., Projects and Case Studies)

Pages like projects and case studies could remain simple, requiring no additional fields. Their structure can be customized through display components to align with the desired information architecture.

Editorial Experience

A flexible data model paired with specific content templates can streamline the editorial workflow. Editors could duplicate a pre-configured page, adjust content, add or remove display components, and then publish.

This approach operates independently of the data model and can integrate seamlessly with editorial workflows (e.g., through a workflow module).

Supporting Functionality (e.g., Recipes for SEO and Search)

The fields Title, Description, Image, and Tags offer robust support for dependent functionalities. SEO meta tags can be generated based on these fields, and advanced search capabilities can use them to ensure effective results across content types.

I understand that the Content Strategy document does not specify technical information like widgets but they are being discussed. I expect that we will use media reference fields for all image fields. I have written up an issue to describe why I think we should not use image fields directly on other entity types like nodes → in Drupal CMS.

Image fields should always be reference fields to media entities. The same should be the case for all other media files loke video, remote video, file, etc. I did not add this to the graphics above to keep them simple.

#6 If I search for type: image in all field.storage.*.*.yml files across the Drupal CMS recipe suite, I'm not seeing any occurrences. So it looks like we're on the right track already...

#7 I dont understand the comment. My suggestion aims at the general way how content is constructed. The fact that image is not a reference field was only to make the concept easy to understand.

I had a nice chat today with @breidert about the general direction of Drupal CMS's content strategy and how it might relate to the end users' information architectures, Drupal CMS's usefulness to agencies, and the technical questions of data modeling and scalability.

What we landed on is that there is currently very little technical guidance about how to build a content type for inclusion in Drupal CMS. What fields should be shared? What dependencies should be there, or not be there? What are the best practices? What should we avoid? How do we resolve tensions between what we think our target audience wants, and what is useful for developers/agencies/contributors?

None of these things are documented, currently. It's all sort of "best guess" based on the combined experience of the track leads and the leadership team (including myself). @breidert expressed to me that it would be hugely helpful if all of this stuff was documented so everybody could be on the same page in terms of what we're doing and how, rather than just having to merely react to my and/or @pameeela's feedback when they submit a merge request.

So maybe I (or someone else) should take a stab at a Google doc, that could eventually be added to the project wiki, that explains how we build content types and why.

Yeah, let's collaborate and make it available to all contributors to Drupal CMS.

Google doc ready for commenting: https://docs.google.com/document/d/1yeWlOWMtozGvDZ-LXDrve5S7u0EBWMln7Oj_...

Do we have next steps here?

I think we should close this issue and start a new one.

We have already started to work on demo content, it is getting quite nice: https://www.drupal.org/project/drupal_cms_demo_content →

From my perspective there are several aspects to the topic of content strategy.

1. Information Architecture / Data model - how we create content recipes
2. Demo content - presenting demo content
3. On-boarding new users - through demo content and explanations

I suggest closing this issue and start new ones.

Agreed, thanks everyone for your input :)

Automatically closed - issue fixed for 2 weeks with no activity.