TYPO3 Core

use case 1:
I need to have a good visual representation of multi-column content in BE. example: putting to arbitrary content elements next to each other

use case 2:
I need to collect multiple content elements, which can be shown in a carousel.

use case 3:
I need to logically group content elements together. example: warp those CEs with certain markup in FE output.

1. I need to create nested containers of content elements
2. I need to create structures like tabs and accordions; these kind of structures (especially the first one) may require to pass some information or content from the content inside the container to the container itself. - may be linked to use case 3 by Markus Klein

what I don't need

1. As integrator I don't need to generate bloated frontend code that is difficult to be adapted to my needs; I would want to be in full control of the output
2. As editor I don't need to be overwhelmed with so many configuration options that I can't understand even half of them
3. As integrator I don't need to be forced to use Bootstrap grid (if I prefer Susy or Foundation), so if you want to consider a feature that builds the frontend grid based on the backend layout, please consider that if you stick to Bootstrap you will force people that wants to use a different framework to do exta labor.

Generating a CSS with display:grid would be awesome, but we need to consider the compatibility with IE 10 and 11

I'm currently avoiding something like gridelements completely - just using "components" taylored to the customers needs. So for "multicolumn" teasers (or accordions, tabs, sliders etc.) I use special elements (components) with child-elements (through IRRE). I can then define the backend fields and frontend output exactly like I (or the customer) want it. So at the moment I wouldn't need "structured content elements" (if you say that this is something like gridelements). I would prefer an (enhanced) solution like mask in the core, to build / edit custom components more quickly and reliable.

Here is our summary for Use Cases:

1. I need a visual structure of multiple columns with arbitrary content both in frontend and in backend with a minimum amount of page templates (flux) / backend layouts
2. I need a possibility to move nestet content elements from one column or row to another via drag & drop
3. I need a flexible amount of rows in a structure (e.g. an accordion) that can be easily extended (plus button) or decimated (trash button)
4. I need a flexible amount of rows and columns where the column widths can differ from row to row as one structure (e.g. a matrix or mosaik). Without having to create it with custom content elements (something like: container 70:30, container 30:70, container 70:30 ...)
5. I need to be able to reorder the rows of a structure (e.g. an accordion) via drag & drop
6. I need a manuallly added (not generated by e.g. backend layouts) backend section witch respresents a frontent section (<section>) that can contain other structured content elements.
7. A parent content element needs to know its children.
8. A child content element needs to know its parent.
9. I need nested content elements to be propperly translated with its parent

Annett's stories are pretty good, though I would like to add another point:
I want to have an option to add flexform like configuration to columns (e.g. for adding different width for breakpoints, force equal height, etc.)

In addition to #83776#note-5

• I want to be able to change class names (override template files) for grid structures (similar to what EXT:form does). Is is important for custom designs with custom HTML templates
• I want to be able to restrict the editor in some actions to avoid him breaking a less flexible website design

This would be really nice but it's a step further into the future:

• there could be a migration tool to migrate gridelements into core structered CEs

When you think of TemplaVoila content elements (fce) there's no great possibility to migrate.

I think using flexbox instead of floating is the more modern way for layouting things and often it makes more sense, to go for a content driven design/layout. But using the full power of this:

• I may need to create a flexible page layout depending on content I put on the page.
• For that I need to configure flexbox options for each column, row and content element. And to make it complete (and unfortunately really complex): all that with different media queries.

By following this approach 100%:

• it would be needed to create CSS Stylesheets on the fly by considering the configuration (containing media queries and styles for each element).

The most modern and innovative way is certainly CSS Grid ;) e.g. https://gridbyexample.com/examples/example12/
Because we need a grid base an not just only a row base

• I want content elements which will be on all pages down the tree
• I want content elements on multiple pages as reference (so only one place to edit them)
• I want different order/show/hides of content elements depending on medium (mobile/tablet/desktop/TV)
• I want to define which CE can be put in which col/rowtype/container

Some non-structured thoughts (usage of must, should, may, etcetera is not strict):

- some sites require a flexible use of multiple columns (or maybe even more complex layouts) with content
- current flexform implementation has quite a few restrictions (FormEngine has restrictions with evaluation of displayCond for example) and the storage method in the database is not to everyone's liking
- structured content elements also need some extra fields besides areas with content elements
- translation of structured content elements and the content elements they contain must be taking into consideration
- when changing the type of a structured content element, content elements may become orphans (e.g. changing from a three column to a two column block). (The page module already shows this for content elements belonging to an unused colpos). Some mechanism to warn editors and let them solve the issue must be made
- integrators would like it if there was an easy mechanism to create structured content elements, similar to backend layouts
- the definition of structured content elements must be stored in such a way that it can be used in a versioning system
- integrators should be able to restrict the type of content that can be used in content areas
- frontend rendering of structured content elements should be done with Fluid templates. There should be a mechanism to render the content areas

And please, no speculation about migration from gridelements/flux/dce/TV+ ... thats a part after the core work.

Dear Santa Claus,

• if I could change, delete or add columns in a page without creating multiple nested contents.
• if I could manage the columns of a page like with the be_layout wizard
• if the columns of a page could be inherited automatically for child pages
• if I could easily drag and drop my content in these columns
• if these columns could automatically have responsive behavior and if I could adjust this behavior
• if changing the columns of a page could be well managed in workspaces
• if I could easily drag and drop unused content in these columns
• if the specific settings for displaying a page (checkbox, drop-down list) were directly accessible without opening the complete page form.

• if the columns of a page were no longer defined by nested contents (but by be_layout)
• if the new design of a site no longer required me to make complicated scripts to replace the contents of an old position to a new position.
• if the columns of a page could be easily set up to match the bootstrap behavior.

If the structured content project is about something other than making columns freely, I am currently very happy with Mask (for specific content), and I find that bootstrap_grid (with gridelement) for columns is an acceptable (UX) solution.

is it possible to contribute ideas in terms of UX?

Cheers,
Rachel

@Rachel Tjong-A-Hung of course everybody is invited to contribute ideas in terms of UX, since this is the original motivation of the common interest group: To improve the TYPO3 user experience for each target group from editors to integrators to developers.

• I want the possibility of A/B- and Multivarianttests

@Rachel Tjong-A-Hung Foucard your ideas seem good; Just some non-structured thoughts

- also interaction via mobile devices should be considered
- I should be able to "lock" the addition or subtraction of columns and rows. I explain myself better: the following scenarios should be considered

a) I have already structured my page into two (or more) columns (like now) and I just want to add content in them without sub-splitting.
a.1) I don't know if the adding of a new CE could be assimilated to the adding of a row
b) I want to provide some already configured row structures (2-cols, 3-cols) without letting people modify them (maybe the proportions)
So we have at least 3 possible scenarios (in order of flexibility low -> high)

1) Just add content element, the structure is already provided
2) add structures that are already built
3) build the structure (rows, columns and their proportions) and then add the contents (your solution)

- I should be able to alter some "settings" of each row: for example I would like to set a different background for each row. So each row could have a "settings" button