Structured Content Initiative

The main goal of this initiative is to build better, native support for custom, semantically structured content element types for TYPO3.

The focus for us is always:
Do not look at the current implementation and limitation, but rather find the best user experience first, then look at technologies!

• We want to create a better experience for editors to work with content types in a more intuitive way.
• We want  integrators to build such content types easily, semantically correct and flexible /re-usable. These content types are not bound to layouts, templates, or technologies like FlexForms.

There are several reasons why people are constantly asking for structured content or content structures in the TYPO3 core for a long time.

Sometimes a flexible use of multiple columns or maybe even more complex layouts to structure content is required. Some use cases developers/ integrators are often struggling with are flexible accordions, content containers as content elements, restrictions on content element placement and drag & drop. Unfortunately some of the current solutions have often led to problems with upgrade or migration.

On top, TYPO3 should provide a semantically correct way for defining custom content types.

This initiative is a long-term project, no specific milestones have a specific time frame yet, however this will evolve while we are planning and create concepts.

There will be monthly Slack calls for exchange between the working groups (of course not all participants of the working groups are required to participate in those). The working groups shall form their own schedule and organize themselves.

First find the best user experience and expectations, and then look at existing or new technologies later.

During our analysis of what we understand as structured content, our expectations of the initiative and taking a look into other CMS, it showed that this topic is very complex.
To achieve results more quickly and straighten the schedule, we identified three main parts which should be covered in separate working groups. These working groups will act in parallel but will constantly share the working progress and ideas to ensure the common goal.

Editing Interface UX

This working group will focus on a concept for UX, creating wireframes, mockups and layouts, to make content management for the editor more intuitive.

Content Block Creation

The focus of this working group will be registration and maintenance to ease up the creation process of content blocks and their hierarchical relationship. This group will aim for a technical concept for registration and maintenance of content blocks as well as a re-evaluation of processes for storing and connecting data of content blocks.

Rendering Group

Containers, wrappers etc. will be the things this working group will concentrate on. A concept for semantic content interpretation in frontend is therefore the first goal to be achieved.

Not in Scope:

• Frontend editing

These are the steps we're tackling as intermediate goals:

Editing Interface UX

1. Evaluate other Content Management Systems about content structures (how is content structured for editors, how are they defined and stored)
2. Create UX wireframes and click dummies (mockups, no prototypes) on how a system for editors could look like, re-evaluating current Page Module, List Module and Form  Engine concepts
3. Create UX wireframes on how to create semantically correct content types for integrators

Content Block Creation

1. Create a concept on how to semantically store content types in the database
2. Define technical details on what technologies should be used
3. Define how to register new elements
4. Create concept for maintenance of content elements

Rendering Group

1. Create concepts for semantic content interpretation in frontend
2. Implement new rendering mode capabilities for different data formats (JSON / XML)
3. Implement modern markup for content elements
4. Implement flexible markup for content elements
5. Implement modern markup with A11Y in mind
6. CSS registration per element
7. JS registration per element
8. Create new default content elements
   1. CSV file rendering
   2. Image gallery
   3. ...
9. Validate DataProcessors, create new when demand is there
10. Make it more easy to fetch data
    1. Auto registering DataProcessors?
11. Introduce filters for FileDataProcessors (SVG, PNG …)
12. Introduce CR10, deprecate Fluid Styled Content
13. Remove gallery processor
14. Introduce new image rendering capabilities (coordinate with Responsive Image Rendering Initiative)
15. Make TypoScript configuration obsolete
16. Introduce new API to replace TypoScript constants

Common

1. Create an action plan on how to integrate this into TYPO3 Core or as an extension
2. Ensure that current native content element types are still working and/or
3. Migration for current implementation of native content element types

• Evaluated other Content Management Systems about content structures and done conclusions.
• Summarized interesting features and current drawbacks to be removed
• Defined working groups and milestones

• Get in touch via Slack: #cig-structuredcontent
• Take a look at: Structured Content on Github

• Forge Issue
• Blueprint