JOURNEY: content dimensions UX

[dimaip]

General

The dimension system, with its fallback chains, is a very powerful concept of Neos CMS. However, if you work with multiple dimension variants within one dimension (e.g. languages) or multiple dimensions themselves (e.g. languages and markets) determining what you are actually editing in that moment can be quite challenging even if you are a pro user.

You have also to take into account that it’s likely that you have multiple independently working editorial teams responsible for a specific sub set of dimensions.

Node Variant Information/Notification: Know where you are and where you wanna be.

One of the most obvious challenges IMHO is to know where you are and what you are actually editing in a given moment. Even with the fallback system it is not 100% clear what you see. Right now, you have an indicator (orange border) showing you what you are seeing, but you don’t know which node variant it actually is.

Depending on the scenario it’s rather important to know where you see/edit.

Scenario 1: Fix a typo

The editor is responsible for the en-us version of a node which has a fallback of en-gb and a general en version of the node. He is going through the content and sees a typo he would like to fix. His obvious workflow is, that he just selects the node and starts typing. If you consider the fallback chain en,en-gb,en-us it’s important that you know where the typo actually is and which dimension variants are effected.

Scenario 2: Deleting a node

The editor is responsible for en-gb (with the fallback chain en,en-gb,en-us) and he decides to delete the node. In this case the en-us version will be altered without notice and if the node also exists in en, it will be rendered again because of the shine through.

Scenario 3: Move node in dimension space

The editor created a node in en-us, which has a fallback chain to en, but no en variant exists. For some reasons he wants to move the node to the en dimension variant. For instance to avoid scenario 2.

Conclusion:

• It is important to communicate very clear where you are
• It is important to jump quickly to the desired dimension variant in order to fulfill tasks quickly
• It is important to move/copy nodes quickly within the dimension space
• It is important to notify/warn the editor about possible implications of the action he is performing
• It would be important to set the default dimension variant for each user to avoid unnecessary dimension jumps
• It would be nice to be informed if someone else changes a node in another dimension variant I’m responsible for

Node Variation Consistency: Translating/Cloning/Copying Nodes

Creating nodes in a multi dimension setup can be quite tricky. Depending on the scenario the editor expects different outcomes.

Scenario: Translating

If an editor would like to translate a node it would be quite handy to be able to see/switch to the original language quickly. Especially if you have to adapt already translated nodes. For instance, imagine an editor is changing a node in en, which has already been translated to ru another editor has to reflect these new changes in ru again.

Scenario: Cloning

The editor would like to copy several nodes in a certain path and create an exact clone with all references within the path. This basically means, that the references within the path have to be altered to the corresponding copies in the new path. Imagine products and categories that have to be consistent within the path and you would like to create an exact copy -> clone.

If you have a multi dimension setup (e.g. language de and en) you might like to copy/clone the path in all dimensions in oder to keep the linked nodes throughout all dimensions even though you don’t have a fallback chain configured.

A use case would be, that you clone the path and start altering it to your specific needs and you specifically don’t want to have a fallback chain.

Scenario: Copying

For an editor it’s not 100% clear that there is a difference between copying nodes to another dimension via the dimension switcher (translate process) or multi dimension copy past. Nodes that are copied via switcher are node variants and nodes copied via “copy past” are new nodes.

Conclusion

• It is important to know if I’m about to create a new node or a variant of an existing node (some identifier)
• It is important to know if node references are updated or not

https://github.com/neos/neos-ui/pull/2164 And other issues.

@robertlemke has suggested that translating of content should have special treatment and not just general content dimensions terminology.

[danielkestler]

I am not that deep into content dimensions, just a thought from my side: the dimensions are some kind of tree, right? So maybe we need a new outliner like the the content structure outliner on the bottom left where you can then see, add and remove node variants?

(The whole concept of all the collapsible inspector, tree and outliner panes should probably be rethought to work more like the panels in Adobe apps...?)

[skurfuerst]

@danielkestler hm, a tree is not exactly correct - it's more of a graph. That makes it more complex for big cases...

(Sorry, just a nitpick from the side ;) )

[danielkestler]

We had a call last week and yesterday regarding this topic with @davidspiola and @kitsunet and came to similar conclusions as @dimaip. As it is a very complex topic, we cannot easily solve ALL the problems at once, so we have to go step by step and aim for the 90% use-cases like fixing a typo and basically "knowing in which dimension you are". Hereby, we had the following ideas I am writing down in this message and made some drafts for.

As I said, I am not that deep into content dimensions, so feel free to correct me if I am stating something wrong.

1. Global Dimension Switcher

This is easy. Move the Dimension Switcher to a place where it is always visible. As it impacts nearly the whole backend, put it on the very top. Note: the Dimension Switcher shows the desired dimension the editor wants to see.

2. Explicit Node Variant Creation

Currently, if an editor makes changes to a node, he implicitly creates a new node variant if it does not exist yet for the current desired dimension. This is bad and in no way clear to the editor. So we propose to make node variant creation explicit.

Default Node Toolbar:

Create Node Variant Toolbar:

You have to click "Create Node Variant" first before being able to edit your content. This way, a lot of possible errors will be prevent to happen.

3. Dimensions Tree

Add a dimensions view underneath the content tree to

• show the selected node variant
• show if it falls back to another node variant ("shinethrough")
• show which other node variants are impacted by editing the selected node

How does it work? Some examples ...

Basic Example:

Let's go line by line ... L1: German | Germany: the fallback language (and in this case, the origin) L2: English | Germany: the currently selected ("desired") AND visible language – a node variant exists here (!) L3, L4 and L6: English (US) | USA, Spanish | USA etc.: the currently selected node variant will be the fallback for these node variants, as there are no variants created there yet (greyed out) L5 and L7: Portuguese | USA and Chinese | Asia: existing node variants in these dimensions... would fall back to currently selected node if they did not exists, but they do.

Fallback Example (variant does not exist yet): In this case, English | Germany is selected, but NOT visible. The fallback German | Germany is "shining through" (visible). Other dependent variants also do not exist besides Chinese | Asia.

Changed Variants: We fixed a typo in English | Germany node variant and immediately see the impact on all the dependent variants.

Added Variant: We explicitly created a new node variant and see the impact on the other dimensions.

I know that the proposed Dimensions Tree is not self-explanatory – the whole concept of dimensions isn't, right? But it indeed solves most mentioned aspects of daily use for power users.

Regarding graph vs. tree: we discussed that (thanks @skurfuerst), but it may work this way because of two aspects ...

1. All node variants "above" the currently selected variant (so the fallbacks for a variant) are indeed a flat list, like a breadcrumb. There is always only one fallback for a given node variant.

2. All node variants "below" the currently selected one can be shown in a tree if we multiply them out. These are all possible dimension combinations based on the currently selected variant.

What do you think about it? @davidspiola @kitsunet Did I get our ideas right? I know we talked about "reversing" the tree (upside down view, so leafs to the top), this of course would also be possible, but I don't know if there are benefits to it.

[DrillSergeant]

Great you guys are working on that. The need for this is growing more and more so thanks to anybody who is spending time on.

@danielkestler I guess the draft-screenshots above (especially the dimension tree) are "photoshopped" and there is no code that I could checkout to test this in my project scenario, right?

I try to get an idea how that would look like in my projects.

[danielkestler]

@DrillSergeant Right, there is no code for this yet.

[dimaip]

Hey, that's an amazing progress right there! Too bad I wasn't able to join your hangout...

A few thoughts:

1. If I understand the "1. Global Dimension Switcher" mockup correctly, it propose to hide the dimension selector behind a toggle. IMO it current selected dimensions should be visible at all times, without having to click anywhere.

2. We have thought about things like "3. Dimensions Tree" before, but there are some problems. Number of all possible dimensions combinations could be almost infinite and that would get out of hand pretty quickly. E.g. imagine 3 dimensions with 20 options in each (20 20 20 = 8000), existing node variants would simply get lost among all potential variants. Also I think that displaying node variants as a tree is rather confusing, as it's not a tree at all. Besides 3 trees stacked one on top of another look a bit intimidating to me :) I feel like our original solution just to show all existing variants in a selectbox gives almost as much value and yet it's much more intuitive to grasp and takes a lot less space (https://github.com/Flowpack/Flowpack.NodeVariantSelector). If it's really important to visualize dimension fallbacks, we could make a button to expand a secondary (i.e. fullscreen) editor with the rendered fallback graph.

Currently we have "Selected element" dropdown at the top of the inspector. It's only goal is to show the nodetype of the currently focused node. Perhaps it could make sense to use that place on top of inspector to display all relevant information about the current node: nodetype, node dimensions, node variants? When selector is collapsed, the same information could be moved in condensed form to the right side of the secondary toolbar.

[davidspiola]

2\. Also I think that displaying node variants as a tree is rather confusing, as it's not a tree at all.

Hi Dimitry, the idea we had in mind is not to show all possible dimensions. The idea is to show the root-line of the current node to its origin (the way down) and all affected nodes (the way up). There might be more variants beneath, but for orientation it is not relevant. On the other hand, the intention is to show all variants that might be affected by changes. Imagine sitting on a tree. The way down to the roots is a straight line and if you look up, just possible routes to the very top are important for navigation. Only those routes are interesting to know, which are affected by changes on the branch (node) you are sitting on. The idea is to give context where you are and what would be affected and not about viewing all possible/existing variants. Show all variants is also very useful information, but for another workflow or user role (eg dimension manager).

[dimaip]

@davidspiola thanks for clarifying, now I understood. Though I still imagine if you navigate to common most dimension variant, there would be quite a lot of affected variants to show! It seems that the usefulness of this widget depends a lot on dimension config, maybe we could later add some config options e.g. showAffectedNodeVariants etc.

[nezaniel]

Since you're kind of playing my song here, just a few comments:

• as for the "fallback" nodes: Those that are to be shown would be the path of primary generalizations beginning at the current node. Nodes may have multiple generalizations, but only one will take its place on deletion. And that's what the "breadcrumb" shows: Which node will be displayed instead if I delete this one.
• Specializations (the nodes "falling back" to the current one) can be displayed as a tree only if duplicates are allowed. Consider market DE -> EU and language de -> en. You can specialize from EU/en to DE/de via EU/en -> EU/de -> DE/de, EU/en -> DE/en -> DE/de or directly EU/en -> DE/de, so viewing from a node in EU/en you'd have to show DE/de thrice. An alternative to the tree view would be a list of all possible specializations (which btw can be ordered in a sensible way using variation weights if necessary)
• regarding the amount of possible node specializations: While the variation graph grows exponentially with the number of dimensions, that should not be much of a problem here. In a system with 8000 possible variants, editors are doomed to fail anyway. What would be accomplished with this approach is visualizing already existent complexity which is always a good thing imho. One configuration I'd like to see is which dimensions to show and which to conceal. In my experience, multidimensional systems work best if most (if not all) of that complexity is kept away from the editor. E.g. in a two dimensional system, one dimension is set to a specific value for the editors so that they can only create variants in the other dimension while the first one is both concealed and inaccessible and thus does not affect them in any way.

All in all I love the progress being made here, this is a feature sorely being missed in more complex installations.

[davidspiola]

* In a system with 8000 possible variants, editors are doomed to fail anyway.

I 100% agree. @dimaip came up with the idea to collect some actual dimension configurations to get a better feeling about the scope. We also discussed that you just need these features starting at a certain degree of complexity (eg. more than three languages with fallback or multiple dimensions). If you have a very simple setup with just two languages without fallback you basically don't need the information.

* In my experience, multidimensional systems work best if most (if not all) of that complexity is kept away

I experience the same. "Regular" Editors aren't rock solid with fallbacks at all. But even if you are an experienced editor you can get lost quite quickly. One thing I had in mind was that it would be nice if you could set the "entry" dimension variant for each editor to provide the best starting point possible.

* E.g. in a two dimensional system, one dimension is set to a specific value for the editors so that they can only create variants in the other dimension while the first one is both concealed and inaccessible and thus does not affect them in any way.

Not sure, but do you think this package would be helpful in this regard? https://github.com/Flowpack/Flowpack.NodeVariantSelector

[dimaip]

Thanks for the very valuable insights @nezaniel!

So what are our takeaways from this? Create editor roles that are bound to a certain dimension preset?

[DrillSergeant]

As just discussed during the lucerne code sprint session, I started https://github.com/neos/guild-ux/issues/9 to collect scenarios of realworld projects.

[DrillSergeant]

I would like to share a solution that we use in a customer project. Goal was to help the editor to quickly find out, in which dimension-combinations the current document is already translated. As the customer has 2 dimensions (countries and languages) we came up with a table presentation (rows = countries, cols = languages). The cells show the state of the dimension combination country/language:

• a dash "-" means the combination is not possible
• translated combinations have a link to the that combination
• fallback combinations have a link to that combination, too and the link-text says where the fallback points to
• untranslated combinations are marked with a big red "X" (not in the screenshot below present)

The dimension-table is toggled via a big red button top right.

Looks like this (not beautiful, but the editors love it):

As this came from a rough proof of concept we did not integrate this into the UI but render it as page content (of course only in backend-context).

[davidspiola]

As this came from a rough proof of concept we did not integrate this into the UI but render it as page content (of course only in backend-context).

Thx for sharing :-). It's definitely a goal to have a complete overview. Did you check out https://github.com/Flowpack/Flowpack.NodeVariantSelector ?

[DrillSergeant]

@davidspiola I saw that package but we decided to have that table to see the combinations of 2 dimensions easier instead of a long list of combinations.

[dimaip]

@DrillSergeant yeah I've also experimented with exactly the same solution. The problem is that it works well only for setups with two dimensions, and for the core we need to have something universal. Also it doesn't visualize fallbacks.

[DrillSergeant]

@dimaip The fallbacks are visible (as text), see my animated gif from above. This could even be improved by maybe mouseover highlights the fallback dimension or something in that way.

I understand we would like to have a solution for all scenarios. But to be honest, is there any project out there with more than 2 dimensions? I did not hear from any yet. And even if there are - lets say 1% - projects with that setup, should it prevent a solution that fits to 99% of other setups?

In our 2-dimension scenarious I already see the editors struggling to fill all dimension with content. Hard to imagine how they would handle 1 or even 2 more dimensions. I assume that those dimension (e.g. a person dimension or whatever) would be either in most cases consist of pure-fallback content or could be easier handled in another way (another page-tree, ...)

[dimaip]

Yeah I think we should find a solution (or even a number of solutions) that would truly satisfy 99% of usecases. I think a node variant selector in the simple form how we implemented it before + more advanced grid that would open in a popup window for more advanced scenarious could be a very powerful combo.

Anyways, I feel like @davidspiola has accumulated the biggest amount of pain regarding dimensions, I'm wondering what's his opinion :)