much better than before, thanks. I suggest to reduce Sidebar to Icons, if User wants.

I like the concept. To me it feels better. The constant resizing when using the menu was a bit disturbing.
One thing I noted: When I have a submenu active (eg components) I don't see anymore an explanation what the "top level" menu icons stand for. I think it could be useful to have tooltips with the name on them, at least when the submenu is unfolded.
It may also be an idea to keep the currently selected (active) submenu open after a link has clicked. Since it doesn't use more spaces than when it is collapsed.
In some cases that may actually allow to remove the sidebar menu within the component. Eg in com_content the component sidebar menu has the exact same entries as the submenu itself. When the menu is open it looks quite redundant having them right beside eachother ?

Looking good so far. I'll give it a proper test tomorrow.

1. The close icon will need to be lighter for a11y contrasts. Probably $white-offset
2. Will need to make sure the 3rd level dropout is scrollable
3. How is this going to work on mobile exactly? As it stands the sidebar is a couple of hundred pixels wide, so there won't be enough space for the dropout.

I'll remove the jQuery and rewrite in vanilla JS fort you tomorrow too.

Looks great! I'd like to have the dismiss button with more contrast, it should have conrast ration at least 4,5. And the sidbar could have less width. But I really like the concept. Thank you, @ciar4n for your work.

@Bakual Ty. As suggested I have amended so the active item is now open on page load. The slide animation is been triggered on load which I will fix once I have a little more time to look at it.

This change does make your first point more apparent as the menu is now more commonly open (top-level titles hidden). Again I will try your suggestion of tooltips once I get the chance.

On hiding the 'component sidebar'.. I believe there was a reason this can't be hidden. I can't remember exactly. I'm guessing something to do with 3PD? It would make a lot more sense to hide it. As you say it seems to be generally an exact copy of the 3rd level menu items. If really needed maybe they can be appended to the menu items in the sidebar or added to a second tab in the sidebar.

@C-Lodder

1. Ty. Color changed as suggested with the latest commit.
2. True. As these have absolute positioning I think we'll need to use a 3rd party script to add a scroll. Probably not ideal as it is an extra resource to load that won't be used very often.
3. Good point. We could possibly have them open under the 2 level parent item?

Thank you @chmst. I have changed the 'close' to a more stronger contrasting color as suggested...

@ciar4n media\vendor\perfect-scrollbar already exists ;)

On hiding the 'component sidebar'.. I believe there was a reason this can't be hidden. I can't remember exactly. I'm guessing something to do with 3PD? It would make a lot more sense to hide it.

I think at least being able to hide it like in J3 makes sense. We added that possibility with 3.3.7 (#4197) to get more real estate space. That argument is valid even more with J4 since the main menu is now left instead at the top.

Ideally it would be nice to ensure we get the main sidebar done properly so that we can burn that annoying component sidebar

Ideally it would be nice to ensure we get the main sidebar done properly so that we can burn that annoying component sidebar

I fear you will not be able to completely remove it. Because there are items that can't go into the regular menu. Eg when you have menu items which only show based on some conditional like the com_fields links (should only show if com_fields is active and the parameter is enabled) or maybe a link which needs special ACL permissions.
The menu system just isn't in a state (yet) where it could deal with such requirements.

Tested this: an already great improvement.

I have tested this item ✅ successfully on c919fc8

I like the idea and in terms of usability it certainly looks and feels better, it's a good improvement. Something that annoyed me a bit was when you click on a collapsible the need for a lot of vertical scrolling and this fixes that. Regarding the toggle for hiding the sidebar when not hovering it I personally prefer it with the toggle, what could be done here would be asking several people to know what the opinion would be regarding this. Should the sidebar toggle remain deactivated then the toggle could be activated only on devices with smaller screens (smartphones/tablets) in order to save screen size in that case.

Ideally it would be nice to ensure we get the main sidebar done properly so that we can burn that annoying component sidebar
We can get rid of it for core but unless you want extensions to maintain two code bases it needs to be "accommodated" in some fashion

Tooltips added to icons when child items are open...

When I click on a parent item, such as "System", then click the "close" button, if I hen want to re-open "System" again, I need to click on it twice.

Thx @C-Lodder

Fixed with latest commit

Hope it's a click with the top parent, not a hover. I'm not sure about the last children level - the hover and right direction is a slight change in the idea.

Ciaran, I'm posting this document here for consideration, as recommended by George Wilson.
https://drive.google.com/open?id=1Z6wAhwW7RM_H5RX3Hg5_T0mpSXXdIL19eZH701R2r6k
I'm at the JUX working group at Glip, or you can message me here.

@jonrz How would that on mobile / tablet

@brianteeman tablets would mostly keep everything in sight. On smaller screens, it would shrink to a single column when needed, and the user would need to either scroll it, or we could have an accordion (still need to do some research on the best method).

i cant see how that would work

I'll update that document in a week or two with proposed mobile solutions.

@jonrz is this the design/structure that the ux team is proposing?

@ciar4n this is a structure I'm proposing to the UX team, so we take it as a starting point and do surveys and research on it. Cliff seemed to like it, and George Wilson recommended me to talk to you about it.
I hope to bring this structure to the active conversation, and evolve it to the point of actually using it, or some improved version of it, on J4.
Apart from make it look decent, I spent no effort refining the design, since I intend it to be a starting point.

@jonrz The design here is not to far removed from what you are suggesting with the exception of some simple enough changes. Not my area but I suspect both the Joomla logo and text would need to be displayed in at least one state of the sidebar.

Structurally (item grouping etc.) your proposal is a bit more major and would probably go beyond this PR. It would be easier for me to accommodate a new structure within the design if and when that new structure is in place.

I would suggest creating an issue on your structure ideas if you want to get that conversation started.. https://github.com/joomla/joomla-cms/issues/new

@jonrz that proposal for the new design seems really great, really like it. Just would change the layout for components part, don't like it as much as the other sections for the simple fact that it seems somehow inconsistent with the rest, but overall seems very good, linear, minimalistic and simple, and easy access to the several parts.

@jonrz your proposal is way to busy, feels like a bunch of modules not a menu. Also you are not simplifying things you just displaying a larger amount of things in a different layout. To me this is not an improvement! Menu should be simple, self explanatory, your version comes from a previous era where menus tend to be huge wannabe everything type of things. @ciar4n is on the right track here, what's left is to reduce the menus items by combining all the system related items into a view e.g. Control panel ( obviously the current control panel needs to be name dashboard) and a way to distinguish data from structure and view. Sorry but huge thumbs down from me

@ciar4n thanks, I'll create an issue.
I don't want to go over the UX group, but I firmly believe this have great potential. The JUX is leaderless at the time, and there is no new lead in sight.
I'll try to work this in parallel there and here, if you agree.

@rjcf18 Thanks. I'll put more thought into the components part.
So far that was what I could come up with, since the components menu can become really, really huge. There are some components with tens of submenus.
I was also thinking of having the first column for favorites. But let me get the new issue online and then we discuss improvements.

The "JET actions" (provisional name) you see there is an Idea I had during a talk with Cliff about the new Dashboard.
It is a helper/wizard component that would streamline administration tasks, helping the rookie user climb the learning curve while actually getting things done.
Please, take a look at it here (work in progress):
https://drive.google.com/open?id=0B6QfGa3p1VQ7bl9vNHFFZExYVDg
This new component ideation is both a UX task and a develoment task, so with your permission, I'll create a new issue to handle it.

@dgt41 All constructive criticism is welcome.

I must argue that I am simplifying things. Consider the new main menu, down to 5 items (from 7, or 8 if we take into account the UX team suggestion for a dashboard icon, or 9 if the modules icon went up a level).
And not only in number of items, but in logical, intuitive organization.

This new menu have the intention of eliminating the "where do I do this and that?! that happens a lot with new (and even intermediate) users.
It is a concise structure that displays fewer and more organized main menu items, with more sub-menus visible once you click in a main menu. It is busy only after you select what you want to do. And it will get things done with less clicks and less fussing around.
It will help the new users a lot to have all content related actions visible, without having to search through different menus and sub-menus.

And of course the design can be better. I didn't spend any effort into designing a nice looking menu. I'm putting up an idea, from the UX perspective, and the talented designers from the Joomla Design group would make it look awesome after we iron out the kinks.

Hmm, I agree with @dgt41 only on the fact that the menu seems bigger and more "crowded" than would be desirable, but this new proposed design still seems self-explanatory and simplified imo, the only thing is it seems big, but it doesn't seem "non-functional" or "imperceptible" in terms of usability. Having a smaller, extensible on hover, sidebar and still integrating these new changes and with some refining this would look really good imho.

@rjcf18 Absolutely, and thank you for your comments.
I hope that, after an agreement is reached on the organization, the design team could put their talent into it.

your version comes from a previous era where menus tend to be huge wannabe everything type of things.

@dgt41 It's not necessary a previous era. To me it looked similar to a Windows 10 menu which certainly isn't a "previous era" ?

The fact it looks similar to Windows 10 doesn't bother me. Windows 10 menu for works well, but probably wouldn't so much for Joomla.

From what I've seen, the proposed design by @jonrz may also result in a massively bulky menu layout, simply because it will be to be changed completely for mobile.

The current (accordion) sidebar does need revamping, however it you look at the menu.php, you'll notice that there no "mobile specific" code. What you see on desktop, you see on mobile, thus a simple structure.

@jonrz - So please ensure you bare this in mind when prototyping ;)

Sidebar toggle option added...

Toggle should stay if selected.

@C-Lodder Thanks. I will keep that in mind.
I'm still doing research for mobile, but my intention is to have a single code for both desktop and mobile.
All the changes will just be on CSS media queries, and I'll try to keep that to the bare minimum.

IMO the toggle button is too far from the actual menu it operates on. This breaks one of the UX rules of proximity. In such case, it says that the whole left column gets operated on, with the logo.

@Milo-W In this case the toggle button is for the sidebar rather than just the menu

@ciar4n still, the button doesn't appear "connected" to the sidebar.
So it may go unnoticed (in function) to the user.

@ciar4n new issue posted: #15536
Cheers.

@ciar4n I must say I somehow saw only the menu collapse (maybe I was looking at something else, the screen from above, the other one). IMO it's still too distant. The hamburger means the menu and it's a bit too far from the actual navigation.

@jonrz it's too large : / too hmmm... "spreading" : /

The hamburger means the menu

@Milo-W A valid point. Leave it with me and I'll see can it be improved

@ciar4n or maybe make the icon more "sidebar-ish"? But then the collapsed view would be:

Look:

What strikes me is that the menu icons get lower in the collapsed view than the full view version. IMO this shouldn't be and they should only collapse, without travelling downwards (again, proximity + kinesthetics).

If it can be done so that the icons don't travel downwards, then IMO this might be a quite valid proposal.

Maybe it's just my copy-paste mistake

@Milo-W - Did you really copy and paste all the code to test this PR?

@C-Lodder nooo it's just an image ; )

lol fair enough.

Anyway IMO, I think Ciarans toggle icon position is better suited. The icon itself can be changed if need be, but position is good, as it means we're not making the list longer by adding it to the top.

Toggle bars replaced with chevron...

@ciar4n dont forget those chevrons will need to be reversed on an RTL system

Thx @brianteeman That shouldn't be a problem

I think in general all template RTL styling will be applied at a later stage.. @C-Lodder ?

OK - was just raising awareness of the issue as you are using an icon which has direction to it now

I'm gonna have to think about RTL. Not sure if the powers have a set date for a stable release of J4, but BS will most likely add RTL in 4.1

They're taking an extreme amount of time to get the first Beta pushed out, so I may grab the PR from the repo and add it as a temporary measure.

A11y tabbing compatibility added...

Also menu closed if on com_cpanel

@armenos

PR now ready for testing!)

We will also need to have the flying focus on the "X" button too, so users can close the 2nd level via keyboard

@C-Lodder Good point. Done.

I have tested this item ✅ successfully on 1aee1fb

I have tested this item ✅ successfully on 1aee1fb

RTC after two successful tests.

@franz-wohlkoenig there are codestyle issue please remove RTC
@ciar4n please fix the codestyle issues

@rdeutz Codestyle issues fixed

@rdeutz set back on pending.