Hello,
regarding the following issue I have no solution in mind but wanted to know whether I was the only person around here to see this or whether at least some of you agree.
While large parts of the UI feel really good the Create new [node] dialog suffers from what I think is an arbitrary segmentation.
I have just had a look into Florian Weiss’ handy Bootstrap package and stumbled upon the term Bootstrap in the Create new [Node] dialog. Since this term makes no sense to editors I asked Florian to change it along with Jumbotron to something more common or useful.
But from a non-developer’s perspective the whole differentiation between General and $whateverNodeTypes does not make much sense altogether. Form and Button or Image and Responsive Image should not that far apart from each other and certainly not in different sections. Then again the term General ist not very helpful at all. On the plus side there is no Other oder Misc section. Oh, wait, there is Plugins …
What do you think?
Hi Christian,
if you could come up with a proposal on how to structure the node types in the TYPO3.Neos.NodeTypes package we are happy to make the organization easier for editors. We could also think about writing a small section in the docs on how to organize / name node types and their groups.
I agree the organization should be done from an editors perspective and not from a technical standpoint. Right now you could override the groups of the node types in a NodeTypes.yaml from your package. You can also change the labels in that file (I think it’s hard to find 100% perfect labels for every use-case, so they’re always somewhat project dependent).
Hi Christian, thank you for your input. The bootstrap package as well as the Community.News package are designed to be easy examples for Integrators on how to create their own nodes, at the current state of development they are not designed as “import and use extensions”. While you could defenitely do that you might want to have at least some small alterations like the descriptions you mentioned.
I see your point and agree regarding the editors, but you’ll be hard pressed to find “the general and common solution” that is well suited for all use cases, therefore I recommend to overwrite the descriptions in your own site package based on what is agreed on with the customer.
I’m open to suggestions on this point however, so if you lay out a recommendation on how to structure the Nodes as @christopher recommended that is agreed on I can certainly adapt the structure in future revisions.
Hello,
thank you for your prompt answer! As I mentioned, Christopher, I don’t have a perfect solution either. And what you say, Florian, is certainly correct: There won’t be an out of the box solution that fits everyone’s needs.
So we might think of something that
a) lets the integrator decide on the segmentation of the dialog,
b) works with every package that implements node types,
c) survives updates of Neos or any of the packages.
Since the original NodeTypes.yaml will be overwritten every time you update Neos maybe Neos should look for an optional file called CustomNodeTypeCollections.yamlfirst. If it is there, the NodeTypes.yamlwill be ignored.
In this CustomNodeTypeCollections.yaml references to packages that are not installed or don’t even exist, would be ignored by Neos.
Apart from the file name and implementation details do you think this is the right direction?
hey Christian,
You don’t have to change the Neos yaml files at al, and please don’t! 
If you create your own nodetypes package and add a requirement in your packages composer.json it will be loaded after Neos (nodetypes). This basically allows you to override / unset / extend the nodetypes configuration from within your own code which will not change if you update Neos.
Example snippet for your composer.json (of course a version constraint would be better, but as a bare minimum this would suffice):
"require": {
"typo3/neos-nodetypes": "*"
}Hello Rens,
thank you very much! I will try that 
One last question though: Is your solution part of the documentation already? If so, could you please post a link? And if not, I would highly recommend even a Neos Integrator Cookbook recipe
I see the composer thing is not in the chapter where I expect it, but the full configuration loading in Flow is described here: http://docs.typo3.org/flow/TYPO3FlowDocumentation/stable/TheDefinitiveGuide/PartIII/Configuration.html
While that looks more like science than hands-on configuration I think I have to deal that anyway. So thank you
I agree the node creation need more love and offer more natural feature (favorits node type per user, share favorits, live search, filtering, …), the react UI solve some issue (like filtering), but introduce new one (position of the node).
We should take care of this in Design System for the Neos products