Epic #84101: The core must provide configurable structures for both pages and elements out of the box
Definition of goals to create the stories
Everybody who wants structured content to become part of the core, please write down the reasons why you think this should happen.
Just write some short sentences so everybody will quickly get your reasoning.
To make sure we are talking about the same things, please read the discussion here first: https://wiki.typo3.org/Talk:Blueprints/ContentElementDefinitions
We will then discuss these reasons on Slack https://typo3.slack.com/messages/C8Z2UM50Q/ and generate user stories based on these reasons.
So before deciding HOW we are going to do it, everybody will know WHY we want it and WHAT we are going to achieve.
#1 Updated by Markus Klein over 2 years ago
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.
#2 Updated by Jo Hasenau over 2 years ago
- Status changed from New to Needs Feedback
- I want to enable editors to make use of upcoming features like the CSS Grid Layout Module https://www.w3.org/TR/css-grid-1/
- I want to speed up daily work by grouping single elements so people can apply actions like "move" or "copy" to just one container instead of each single element.
- I want the backend to be working without static structures, so people can use it on mobile devices too.
#3 Updated by Riccardo De Contardi over 2 years ago
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
#4 Updated by Tobias Wollender over 2 years ago
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.
#5 Updated by Annett Jähnichen over 2 years ago
Here is our summary for Use Cases:
- 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
- I need a possibility to move nestet content elements from one column or row to another via drag & drop
- 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)
- 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 ...)
- I need to be able to reorder the rows of a structure (e.g. an accordion) via drag & drop
- 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.
- A parent content element needs to know its children.
- A child content element needs to know its parent.
- I need nested content elements to be propperly translated with its parent
#7 Updated by Moritz Ahl over 2 years ago
- File add and change rows.png View added
- File edit properties.png View added
- File inline-editing-content.png View added
One remark: Let's not re-invent the wheel UI-wise. Have a look on wordpress page builder's UI (e.g. visual composer). I don't like them as a developer, but I love them as an editor! See the screenshots attached.Some other thoughts:
- I think a "custom content" element (slider, accordion) is another thing as a "container" element which provides layout structure (row, column). It needs a different UI, behaves differently and the page module is the place to interact with it. And is the relation between a column and its content the same thing as between a slider and its slide? While it might be technically alike, it is a different thing UI wise. The implementation should consider this.
- Do we really need infinite nesting of rows/columns into other rows/columns, for example 50:50 inside another 50:50? Often it's just a lazyness thing because it takes so long to create 4 columns à 25.
- maybe it is wise to limit the scope to handling rows and columns - and do this one thing well. There are solutions for custom elements out there which would still integrate nicely.
- Editing layout/structure (read: rows and columns) should happen in the page module. Re-Arranging cols/rows, inline editing and drag n drop play an important role to make it easy to use for editors. And since the page module is part of the core and hard to extend or modify, I think the core should address this topic.
Here's some more stories:As an editor...
- I want to create rows "on the fly" inside a page or above or below other rows, in order to place content or columns in it.
- I want to be able to insert content or columns into rows to place content in it.
- I want to create multiple columns in one row with predefined divisions (for example, 1/3 + 2/3) with just two clicks
- I want the visual representation of the columns to reflect their widths.
- I want the last column exceeding the max. available row width to break up to the next "line"
- I want to move rows below or above other rows (nowhere else!)
- I want to move columns before or next to other columns (nowhere else!). It must work even across rows.
- when moving rows or columns, I want their columns and content to moved with them.
- I want to delete and duplicate rows, columns or content elements.
- I want to edit the properties of rows and columns in a modal to change behavior or looks quickly, for example the width.
- I want all changes to the structure (create, delete, move, edit properties) to be visible instantly, without reload or leaving context.
- I want to quickly change the divisions of all columns in one row preserving the content in it
- I want to cut, copy and paste rows (including their content) across pages.
- I want to be able to define a grid system in one template instead of independent files for each configuration (30-70, 70-30, 20-80, 20-60-20, ...)
- I want to re-use grid elements across projects and be able to download for example bootstrap grid definitions with pre-defined properties for columns and rows which make sense for almost any project (width as in 1 to 12, responsive behavior settings, maybe padding and margin?) with a nice UI
- I want to be able to define custom properties for rows and columns as I like
#8 Updated by Lidia Demin over 2 years ago
In addition to #83776#note-5As a developer:
- 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
#10 Updated by Andreas Steiger over 2 years ago
I really like the thoughts of Moritz Ahl. We should orient ourselves to well-functioning concepts. But not just Wordpress ;) See my short screencasts attached. We also can have a look on website builder WIX (I know this is frontend editing, but I like the UX for creating columns) and the new Emotion/landingpage Builder of Shopware. Of course, this builder for landingpages and other stuff is a bit buggy and when I set a 12-column layout, it does not work anymore on mobile screens... but I love the concept of switching viewports and linking elements between the different viewports in a simple way. This is an innovative UI for managing content for responsive screens I think.My additional use cases and stories:
- As an editor, I want to split quickly my content into 2,3 or 4 columns with an user-friendly UI
- As an editor, I want to put my content in a section/row in order to separate it visually in the frontend. (Alternating colored backgrounds on a landingpage)
- As an editor I don`t want to put a container item in a container item within a container item
- As an editor I want to reorder my content for mobile devices and hide elements
- As an editor I want to synchronize my content between viewports, but also be free to cut the synchronization for one special viewport
- I need a multi-selection of content elements to move more than one item (without additional container, as it is with EXT:gridelements)
- I don`t need a confusing wireframe view with many many nested containers and a horizontal scrollable Screen
- I need strong defaults and a editor-friendly UI (not developer-friendly)
#11 Updated by Falk Röder over 2 years ago
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).
#13 Updated by Alexander Opitz over 2 years ago
- 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
#14 Updated by Jigal van Hemert over 2 years ago
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
#16 Updated by Rachel Foucard over 2 years ago
Dear Santa Claus,as an editor, I'd be really happy:
- 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?
#17 Updated by Coders.Care Extension Team over 2 years ago
@Rachel 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.
#20 Updated by Riccardo De Contardi over 2 years ago
@Rachel 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