RFC: Better Dimension support in Neos UI

@dimaip started a poll on twitter the other day and asked what kind of improvement people would like to see. I suggested better dimension support and some other folks jumped in as well. That’s why I’m gathering the feedback regarding that topic.

Show node usage in other dimensions:
For editors, who are working in a multi dimensional workspace (eg. language), it would be very helpful to see if the currently selected document node is defined within other dimensions. In general better feedback for the editor would be very helpful in that regard.

Confirm deletion of a node:
For instance, if you have a German (DE) and an Austrian (AT) language dimension and the DE is configured as a fallback of AT, deleting DE could lead to an inconsistent content representation for the AT variant. Nodes defined in DE would simply not be available anymore.

A possible solution for that (IMO expected behaviour) could be a confirm message before deleting a node, if it is defined as a fallback and exists in that other language version.

A more complex solution would be, that you get a copy prompt popup asking you if you would like to copy the missing nodes to the AT variant if you delete the DE node.

The basic question is what is the expected scenario anyway?

Optional editor notification before creating a new document node
Imagine you are an editor from France responsible for translating/creating content for the French market. The base language is English and lots of document nodes are already created. If you are NOT aware of the process of copying nodes from the English version before starting to translate it, you end up with two separate document nodes which are not linked to each other as they are supposed to be. In my experience that editor starts creating new nodes instead of copying them.

tl;tr the process is often unclear for the editor

@kapale create a related github issue -> https://github.com/neos/neos-ui/issues/1860#issuecomment-387343164

A simple message for new editors would help a lot to guide the editor into the right direction before accidentally starting a mess.

If some of you have more or better input in that regard, I would be more than happy to improve this RFC


I think there should be different modes:
a) Node exists only in the current dimension (the default)
b) Node shines through from a different dimension
c) Node exists in multiple dimensions

How would it be represented visually? By yet another icon? Then how would these icons combine with hidden and delayed icons?

How would it work? Would you mark the dimension with some setting in Settings.yaml, and then display a prompt for all document nodes created in that dimension? Might even make sense to have 3 modes:
a) default, creation allowed as usual
b) warning, you get a promt but can dismiss it and still be able to create
c) enforced, you get a promt and no way to dismiss it, to make sure there are no nodes in dimension A that don’t exist in dimension B.

I’ll check with the ux guys. @dfeyer might have n good idea.

Sound way promising. What are the next steps, visuals?

Well, I don’t think this part requires any special visuals, maybe just some feedback when it will be already implemented and under review.

The important thing here is to get everyone agree if this is the way to go and that there are no better ways to do that, my experience of working with dimensions is pretty limited.

E.g. @robert @kdambekalns @christianm, wdyt?

Hey good to see this topic brought up again. The current UI implementation for dimensions is pretty basic, kinda like the least workable solution, and we always had a lot more in mind.

One idea we had was to have the dimensions for a specific node in the inspector so an editor can see exactly which dimensions are selected and available to choose from and thus also allow changing from one dimension to another. Or possibly ask if the user wants to copy instead of switching the dimension.

Additionally we had an idea where it would be possible to customize the selected edit / preview view, instead of only allowing preset ones. I’ve attached some UI mockups of that.

The dimension information / selection for a specific node would look similar to that.

Another idea was a split view for translation allowing having two iframes next to each other with different dimensions selected, e.g. default language and some other language.

Would be great if such core functionality wouldn’t be coupled to inspector. Our editors are often working while having inspector collapsed (especially after I installed the StructuredEditing package), but it’s very important for them to clearly see the active dimension still. They quite often make mistakes when they were editing text in the wrong dimension, because the dimension selector wasn’t visible when entering text.

This is an important topic which some clients really struggle with, and to be honest: Without database access I would feel lost sometimes too.

For one client we created a Preview Mode to show other Dimension Variants of the current DocumentNode:

And in the InPlace Editing we added Dimension-Labels to ContentNodes to show which Dimension is currently displayed:

This helped already a lot, even if it’s still a rough solution.


Think you misunderstand. I’m talking about a nodes dimensions, not the selected edit mode/preview dimensions. Since that’s related to the currently selected node and it’s metadata, the inspector makes sense. I’m not suggesting moving the existing edit mode/preview dimension selector.

Ah, indeed, in this case I don’t object at all.

Hi Stefan, @jonnitto shared with me a github gist addressing the topic in a different way (https://gist.github.com/jonnitto/0b1a93f88329c03b127f63532c60ef2d). I didn’t test it so far, but I guess doing this on a node level is not a bad idea, since you already have some information with blue or orange outlines. To add something to the mix, I kind of like the idea of having a"dimension tray" optionally sliding up from the bottom to display more detailed dimension information. A colored outline, a slide over toolbox and a tray could be a strategy to bring it to you attention quickly, but would also give you in depth information if you need it.

A few years ago I created a mock up for a dimension timeline tray that might not be 100% related to the issue, but is definitely going in the same direction.

@davidspiola The second screenshot is showing basically the same, as @jonnitto’s snippet goes back to dotpulse times too.

Interesting idea with the timeline-thing. But every solution gets quite un-handy with many dimensions…

My questions usually are:

  1. What dimension do I see here?
  2. What dimensions of this node exist next to the current?
  3. What happens if I delete this node dimension?
1 Like

If we get this right, this would be another killer feature for Neos. If you have multiple content dimensions and/or one dimension with many variants (e. g. languages), you will get lost very fast. So I’m delighted that @davidspiola bring this up again.

Has someone input in which way other systems handle multiple dimensions? Perhaps we can catch a great idea/inspiration there.

Other Question: How big is the impact to this topic if the event sourced CR comes?

I tried to implement this in https://github.com/neos/neos-ui/pull/2164
Please review!

1 Like

This idea has been implemented by me and @davidspiola in https://github.com/Flowpack/restrict-creation
I think it would be cool to bring this functionality into the core eventually, it just want to release it as a standalone package to let the ideas boil out. Please test and provide feedback!

1 Like