I like this. A clear approach, removes less used items from the main navigation and gives an opportunity to detail the purpose of some of these lesser used items.

How will it look like when you click on Components -> Banners? Will a third column open?

@laoneo The PR is on the structure of the menu and how best to group menu items rather than the design. The design is branched from #15430

Closing here, @ciar4n will come up with a slick design

JUX is working on a similar, but more advanced and leaner information architecture for this menu, with a good amount of reorganization.
Our initial proposal will be up in a month.

Based on a talk with @dgt41 and the JUX group, we agreed on a temporary compromise for the menu.
Here is the file. The horizontal display is just for better visualization of the worksheet.

The JUX will now work on the design, and make an official proposal as soon as possible.

Much better than your previous proposal you shared. Only one item looks wrong
Multilingual Associations - I would think that should be in your content menu or in your tools menu

Contacts also do have fields.

Why in the content menu?
Associations also deal with menu items associations

@infograf768 thats why I said ...or tools menu

Install Languages missing in "Extensions"

Not sure either about placing Modules in CONTENT.

@jonrz you keep all these useless menus under control panel and help. This PR was to remove all the links that clutter the menu (reasoning in the description)
So basically my proposal was something like this:

UX team proposal is

Your proposal is not removing any system menus or help links, so the clutter of the menu remains.

This is just the organization.
Your style for control panel and help remain (but I had to show it somehow).

Sent from my Samsung SM-G930W8 using FastHub

@jonrz if the links for control panel and help are not dropdown (containing children links) then this is ok

I tried to replicate your groups for the control panel.
Items in bluish are supposed to be highlighted.

Sent from my Samsung SM-G930W8 using FastHub

Did a few adjustments, and fixed the issues pointed out by Allon, Brian and infograf768.
The JUX team is still taking a last look for outstanding issues, but I feel this is pretty much it.

@brianteeman Thanks. I feel we reached a good initial compromise for J4.
I still hope for some revision when we present the layout/design, but nothing major, and I don't want to drag this longer than needed, since we have lots of other issues to tackle.
The Control Panel also has a "Languages" group. I think Multilingual Associations will fit better in there. Agree?

re multilingual - no not really

@brianteeman
Can I ask why?

If you use it you will see ;)

It is for creating content etc in a multilingual environment whereas the language stuff is just for setting things up

I know what this is for. My reasoning for this is group not only by direct function (I know it is a tool) but by meaning.
It deals with languages, so for the basic user it makes more sense to find all language stuff within the same group.
Same as the search issue we had a few days ago. For the user, there is no reason in seeing seemingly related functions scattered all over.

No. It deals with all types of content etc.

I will @infograf768 explain its importance. But it's a fundamental extension for any multilingual site that will be used constantly. It is not just a tool for setting up your site.if anything it is more to do with site building than most other things

So, back to components because it's frequently used?
If it is within the control panel, it won't make it easier to use or to understand if we place it under tools than if we place it with Languages. Maybe half a screen lower on the scroll, and that's all. We won't inconvenience site builders, and we will help new/inexperienced users.

My question will be simple:
Where would you put the CCKs? Seblod or K2 for example.

Multilingual Associations should be in the same group.

@infograf768
That's a fair point. We were trying to keep components a bit cleaner, but it makes sense.
We will try to determine the percentage of multi-lingual vs single language websites, and place it based on actual and projected use frequency. If we don't get the data to evaluate that in time, components is most likely to be its destination, so we won't make life more difficult for current users.

This will be solved else where by someone else

very good thanks !

for me multilanguale association need to be in content for 2 raison

• it realy a good function and in tool nobody realy use it
• this tool is realy powerfull for content translation
  for me its realy logicial to be in content part