@macolo Interesting thoughts, here's my experience with our clients:

Copy/paste

Not really a big issue; I don't think any of our clients/editors have ever raised this.

Rows and Columns

The complexity is definitely an issue for our clients. When we template out articles/bios/services, etc., we remove the need for editors to get involved with rows and columns.

But on landing pages, we essentially have an empty template that leads to lots of questions/confusion for editors who don't use the system every week. We try to get around this by having an unpublished "/templates/" section in the sitemap where we have pre-built examples they can copy/paste/edit, but it's definitely fiddly.

We talked about building something that allowed you to create "Templates" in the plugin list when you click + to add a new element. Users could save existing row/column layouts as a "Template" and then re-use them later from the plugin list instead of using individual plugins. We never built it, but I'd happily outline our thoughts in more detail.

The other alternative as you say is to simplify it but my concern is that clients always manage to find a 5 column layout they need so how would that be built outside of the "standard" 2/3/4/6 column layouts?

In text plugins

I don't like these, so we discourage clients from embedding; they have link/button functionality in a separate plugin, so we encourage them to use that. When we switch over to tiptap we might hide it completely to stop them from doing it :)

• remove in-text element functionality altogether? It's mostly used for links and buttons. Links are solved natively in djangocms-text now and buttons are mostly block elements that could be added after a text element.

With djangocms-text you can specify white and blacklists for text-enabled plugins. I.e. you can install plugins and control which are available from within text fields. To disable them altogether, use the following setting:

TEXT_CHILDREN_ENABLED = FalseTEXT_CHILDREN_WHITELIST = ["NONE"]

(in future releases, this will just beTEXT_CHILDREN_ENABLED = False)

With respect to an improved editor experience and overview on the structure of plugin trees I have had the following thoughts for a while now:

• Allow for some (not too strong)colour coding of wrapper elements, say, grid plugins, so it becomes easier to identify a grid structure. (Same for accordions etc.)
• Allow for plugins to mark them asnot editable (i.e. double-clicking will not bring up a modal). They can be added/changed programmatically by a parent plugin. Example: A row plugin could manage its columns. A hero plugin could manage, say, three slots represented by three child plugins: an image, a header, and a body.

I for instance created a special mixin class which can be added to any component. It adds an extra checkbox to hide that component when rendered. In the structure editor, this component then is styled as shown here:

I also would like to recap my discussion from 2017 added to the discussion board in June:#7969

Here are a few small usability issues that I noticed whilst getting used to the django-cms UI.

If you add a plugin in the structure editor that has no extra configuration it shows you this modal. It would be nice if this modal did not show in this situation.

Also, if you are adding a child plugin to another plugin and it only has one available option you still get prompted to select a plugin. It would be nice if in this situation the only available plugin was just added.

I think combining these two UI tweaks would make for quite a nice experience, although I admit those two combined is probably an edge case.

possible solutions
stop endorsing bootstrap-based website setups and come up with a css grid framework independent approach for columns / layouts. For example, in most layouts, 2-columns, 3-columns, 4-columns, 6-columns and a flexbox container is probably sufficient. What's a best practise to implement such a simplified column approach in django CMS?

@macolo Do you think we should move to something like Tailwind as that is mostly a de-facto standard now or do we go with a generic solution without endorsing a specific framework?