GUI & UX Question? Dimension-Selector's new place

Hey,
in a current project, we deal a lot with dimension-changes language/currency. Dimensions is such a cool work. Compared to other CMS simply brilliant – Thank you core-developers!

##Super easy daly-work with dimensions
I love the easy way with the shine through fallback dimension. It makes the work so easy and the needed changes such little.

###Danger to write in the wrong dimension
What I have realized too, is the danger of double occupancy in the easy-peasy daly-work.
It’s such simple to overwrite the «wrong» dimension in the heat of the moment and when dimensions are in the same language but different regions/targeted consumer/only currency-diff/small spelling diffs(like ch/de).
Maybe I’m the only one with this pit. But:

In daly work I see, some stuff to change in the fallback shine-trough dimension. Do this and that. Think about the needful changes in the other dimension. switch to this, do stuff there, jump to the next, …
Really easy to work! – Then, oh, an idea for the SERP-Description, or a base change for all site, or the title, or what ever : BANG! :anger_right: Did in wrong dimension :persevere:.

####No easy clean-up for wrong dimension stuff
Do stuff back, when overwritten and saved in the second, third or fourth dimension, BUT NOT in the right fallback-dimensions is hard and dangerous hand-work …
I know, it’s my fault, but in daly work it happens more then once.

Very hard to go back, because of the created new node-content-value-entry in 2 DB-tables. I only found the way over the manually clean of the two involved DB-tables.

##Do you know a more simple way?
If you would have an less dangerous way to clean-up wrong created dimension from a node totally –
:pray: Please push me in the right direction!:relaxed:


#A possible help/solution could be…
The dimension-Selector have to share his GUI-location with the text-formatting stuff. Also he don’t like to come back, when the space would be free…
So in daly work, most of the time, the dimension-selector is hidden.

… the own place for Neos-USP «dimensions»

Why, in Neos-Backend there is such huge empty place beside the Editor-Menu? Maybe there could be a better place for dimensons-menu/selector. With this place, the dimension could be all the time visible. At least, editors could better realize in which dimension they do stuff.


Nothing is pefect, but …

I know, not perfect to prevent faults – But I guess a lot better chance to see a fault before he grows up at five different nodes in the same document!
Also less needed site-reloads to «get back the dimension-selection visible» and with this get back «the secure to edit at the right place».

What you think about?

Do I this in a wrong way? Or is this a common fault also for other editors?
####Please share your thoughts.

Question to the core team?

What you are thinking about?
If the place and implementation could be a good issue, where I could/should write it down? (Github Issue? some special place? special tag?)
Are there some thoughts/plans/work in progress in a similar direction? Doubled issue?

2 Likes

Hi Martin,

I’ve heard of other people having the same issue or asking the same question before.

Can shed some light on the reasoning for it being hidden.

In short it’s a due to limited amount of space available in the user interface.

The dimension selector is only shown when no content elements or editiable text on the document are selected. This is due to the bar only having limited space and the editor toolbar needing a lot of space if many options are enabled.

Also it’s not put it into the top toolbar, but in the context toolbar as it’s related to the current document.

For these reasons the current behavior makes sense, however for the new UI there’s a suggested change to move the editor toolbar into a floating toolbar next to the text being edited. This will solve the space issue so the dimensions could remain visible all the time.

See https://github.com/neos/neos-ui/pull/460

Yes this is something that we have in mind splitting the editor toolbar (bold, …), based on the currently selected node, and the action toolbar (language, …), based on the current document. See some mockups here UI Visual Language, a high level view