The Power of Three
Give editors what they need and get out of the way
There are plenty of things worth keeping in your head while building a page. The message. The audience. The right image. The sentence that still does not quite work. Whether this particular element is allowed in this particular place should probably not be one of them.
Neither should the exact number that still fits there, which choices make sense in another area, or which destination will reject something after you have already tried to put it there. Those are excellent problems for software to worry about.
And once a system knows its own structure well enough, it can start doing something genuinely useful with that knowledge. Not by adding more instructions, more options or more things to remember, but by making everyday work feel more obvious.
That is where a little wizardry starts to become surprisingly useful.
Estimated time to read: 5 minutes
Some of the magic was already there
Two familiar ideas were waiting for a third
Grid Elements did not arrive in TYPO3 with a completely foreign idea of how structure should work. Part of that thinking had already found its way into the Core.
The Grid Wizard belongs to the same line of thought that began in 2009 with Grid View and Backend Layouts. Rows, columns and meaningful areas gave the structure of a page a visible form in the backend. Grid Elements later carried that same structural language into individual content elements.
The New Content Element Wizard is familiar territory too. It is TYPO3's standard way of choosing what to create. Grid Elements has no reason to replace it. What becomes interesting is how much more useful that familiar wizard can become once the surrounding structure already knows what belongs where.
And then there was the third one. The Drag-In Wizard is Grid Elements' own addition to the family. It takes the available choices and brings them directly into the place where editors are already working.
One wizard shapes the structure. One helps choose what belongs in it. One puts those choices within reach. That is where three separate pieces start behaving like one authoring workflow.
First, shape the structure
Give content a meaningful place before filling it.
The Grid Wizard is where the framework begins. A layout can describe several rows, different numbers of columns, spanning cells and all the other geometry needed to make a structure visible. That works on the familiar page level and, through Grid Elements, inside content as well.
But geometry is only the visible part of the job. An area can also know what belongs there. It can allow certain kinds of content, disallow others and decide how many items are useful before enough really is enough.
That turns a column from an empty rectangle into something much more helpful. A place can already carry part of its purpose before anyone puts content into it. This same idea also reaches back into page-level Backend Layouts.
TYPO3 14 now supports allowed and disallowed Content Types for Backend Layout columns in the Core itself, which is a welcome step in the same direction. Grid Elements has been doing that in a broader structural model for much longer, including limits such as maxitems.
For editors, the important part is much simpler. The structure remembers. A reliable authoring workflow should not depend on the equally reliable memory of every person using it.
Then, narrow the choices
If the place knows the rules, let editors benefit.
Once an area knows what makes sense inside it, presenting every possible Content Element starts to look slightly absurd.
Imagine opening the New Content Element Wizard for a carefully defined little area that is meant to contain just one kind of teaser.
There is little value in scrolling past plugins, forms, tables, and everything else the installation happens to provide. The system already has enough information to do better.
Grid Elements uses the restrictions of the actual target area to narrow the New Content Element Wizard accordingly. Open it somewhere else and the choices can be different, because the context is different. That may sound like a small detail. In daily editorial work, it changes quite a lot and can make editors noticeably faster.
Instead of learning which twenty options should be ignored, an editor can concentrate on the few that make sense here. A new colleague does not need the same collection of unwritten rules as somebody who has worked on the project for five years. And a perfectly valid option elsewhere does not have to clutter the current decision.
More knowledge in the system creates fewer unnecessary choices for the person in front of it. That is a rather useful trade.
Now, put it within reach
and bring the choices into the work itself.
The New Content Element Wizard already knows what can be created. The Drag-In Wizard takes the next step and puts those choices beside the structure they belong to.
Open it in the Page Module and it looks at the structures currently available on the page. If a particular element has nowhere sensible to go, there is little reason to offer it. If at least one valid destination exists, it can become part of the selection.
Then comes the fun part. Pick something up and the structure responds. The places that can accept that element become available as drop targets. Areas that reject its type stay out of the way. A cell that has already reached its limit does not invite another guest to the party.
Selection and placement become one motion. The Drag-In Wizard does not invent structures behind the editor's back. There is no mysterious automatic grid generator hiding under the table. It works with the structure that is already there and uses the knowledge stored in that structure to make the next move easier.
That is a subtle but important difference. The editor remains in control of what the page becomes. The system simply gets much better at showing where each next step makes sense.
Structure-first Authoring stops being a concept and becomes something you can do with a mouse.
You’ve got to start with the customer experience and work backwards to the technology.
Less to choose, less to remember
Powerful should feel simple where it counts.
There is a peculiar idea in software that simplicity must somehow be measured by how little it can do. That may be a good metric when discussing code or package scope. It is considerably less useful when somebody has to work with the result all day.
Editors do not experience the number of internal classes, listeners or features. They experience decisions. Which element do I need? Is it allowed here? Is this area already full? Can this go inside that structure? Why did the thing I just dragged over there get rejected?
Every one of those questions that the system can answer itself is one less interruption in the actual job. This is where “keep it simple” and “don't make me think” become much more interesting. Simple should describe the experience of the person using the backend. It does not require the machinery underneath to be simplistic.
Sometimes more capability under the hood is exactly what makes the surface calmer. That is why powerful does not have to mean power-user friction. Grid Elements can know about rows, columns, nesting, restrictions, permissions, context and valid destinations. An editor does not need to understand the machinery behind any of them to benefit from it.
That power is useful precisely when it turns into fewer irrelevant options, clearer destinations and fewer avoidable mistakes. Developers are not the only people invited to this party, though. A backend exists for the people creating and managing content. If additional logic helps them work with more confidence and less friction, then that complexity is doing a very good job of earning its keep.
Built for Humans
Let the system carry the details
By now, the three wizards have done something rather more interesting than save a few clicks. The Grid Wizard gives structure a visible form and a set of rules. The New Content Element Wizard uses those rules to make the available choices more relevant. The Drag-In Wizard brings those choices directly into the working area and lets the structure guide placement as it happens.
None of this removes editorial freedom. It removes knowledge that never needed to live in an editor's head in the first place.
The message still needs thought. So does the audience. The right image still matters, and that one sentence may still refuse to cooperate for another ten minutes. Those are human problems worth spending time on. Remembering whether a particular Content Element is allowed in a specific column is a problem the system can happily keep for itself. That is what Built for Humans looks like in practice.
A powerful, modern authoring system does not have to expose all of its power at once. It can use that power to make the right possibilities easier to find, the wrong ones harder to stumble into and complex structures surprisingly pleasant to work with. And once structure knows enough to help the person building the page, another question starts to become interesting.
What happens to all that structural knowledge after the backend has done its job? Layout, child elements and relationships already have meaning for the editor. How much of that meaning can travel with the content when somebody else, or something else, becomes the consumer?
That is where our three wizards leave the stage. For now.
Grid Elements brings three wizards into one Structure-first Authoring workflow. The Grid Wizard defines structure and rules. The New Content Element Wizard narrows the choices. The Drag-In Wizard brings valid options and destinations directly into the working area. The result is powerful software that asks less of editors. Structure remembers what belongs where, so people can focus on the content. That is Built for Humans. And next, we look at what happens when that structure leaves the backend.
Testimonials
Coders.Care is the logical progression of the cooperation between providers of TYPO3 extensions and their users. Especially the point of communication during the preparation of a project will be optimized thereby. The developers can focus on their strenghts, while Coders.Care deals with questions, answers and management. In the consequence there will be clear statements about maintenance and further development of TYPO3 extensions, so the trust in TYPO3 and the projects implemented with it will be strengthened. As a TYPO3 agency we can only benefit of such a service.
© Copyright 2026 Cybercraft GmbH