[4.0] [RFC] The component sidebar

[ciar4n]

A couple of issues as I see it with the current component sidebar location..

• Takes up a key area of the list view even thou its purpose is often questionable (often a duplicate of the component menu items children)
• Causes a large area of white space below it
• Reduces the width of the table
• 2 sidebars side by side just seems wrong

Current component sidebar (Articles, Categories, etc.)...

Some alternatives

• Incorporate in to the main sidebar somehow (Eg. a 2nd tab within the sidebar)
• Add to a dropdown (Eg. dropdown from a button beside the search field)
• Horizontally below the header. Personally I favor this solution as it makes logical sense and simply looks neater...

A drawback is you are somewhat limited to the number of items it can contain without horizontal scrolling.

[ciar4n]

So Fields looks like its Articles -> Fields deep.

Does that not make it correct? Currently Articles -> Field groups gives you..

[mbabker]

The sidebar is in essence a submenu. The only thing that got "goofy" about it is when we started plugging filters into it as well, but that's now completely phased out in favor of Search Tools. So I don't think going back to treating it as just a submenu space is all that bad.

Plus, a component that still wants its own 3/9 space with a sidebar and main area can still do that if they desire without having to "fight" with the template's main elements.

[frogydiak]

If I may, I agree with @ciar4n having two sidebars in the left reduces the real estate which is crucial to data lists. Why not make the 2nd level submenus to go down like in this admin template: http://www.themeon.net/nifty/v2.6.1/ notice the Menu Level section when the sidebar is open and close.

[ciar4n]

@frogydiak I'm guessing your suggestion is related to the sidebar rather than the component menu? I like the idea and for a time we did have something similar. Some of the reasons why this did not work and it was changed...

• As we are using a fixed sidebar menu, an accordion menu is more likely to need a vertical scrollbar which is not ideal. Remember some of Joomla's submenu can have a large number of menu items depending on what extensions have been installed.
• Currently Joomla's menu has 3 levels. This can be cumbersome with a dropout menu (sidebar closed)
• Due to the fixed sidebar, the dropout menu could potentially dropout outside of the viewport

Ultimately this menu will probably be changed again. I have changed this menu multiple times already depending on who has been involved in the conversation at the time. So personally I'll be wiping my hands of it until a decisive decision is made that everyone is happy with :)

[frogydiak]

@ciar4n Thank you for expounding the reasons. Yes, I am talking about the Joomla main sidebar menu and not the component menu.

• I was surprised really after installing J!4 and seen that the new backend template is adapting popular admin themes. If you noticed, if not all, but almost all designers are presenting menu items as accordion and the need to scroll. Logic dictates that it is a must just because the number of items are unknown and the theme has to maintain a certain layout to stay useable. May I ask what is the cause for you saying "scrollbar is not ideal"?
• I respectfully disagree with you on this by saying the dropout menu is cumbersome when the sidebar is closed. It actually give focus to the user which menu item is active and what are the available submenu items. I think this is a matter of personal taste, currently, how level 2 menu items are displayed, to me is more cumbersome. To me, I don't need to see all of the submenu items. Maybe if we'll find a way to make the menu items to be more intelligent, like it sorts itself by most used menu items, that would solve the issue for some people who does not like to scroll through, just a thought.

I understand :) like in urban slang "it sucks to be you" everyone has an opinion. I would gladly say that if you ask my boss he would like this current menu behavior because his brain is wired that he has to see everything, else he don't understand, my dilemma actually.

If I may suggest, instead of reinventing Joomla admin theme from scratch why not adapt work from designers who designs admin theme for a living :) like https://adminlte.io/ v3-dev is using BS4.

[ciar4n]

@frogydiak If you have time to kill have a look at #15430. This was the original PR and subsequent conversation that has the sidebar in its current state. As you can see it all depends on who is involved in the conversation at the time that ultimately makes these decisions. Design by committee is not ideal but that just seems to be the way it is. That PR was simply my attempt to address as many of the concerns previously voiced as possible.

May I ask what is the cause for you saying "scrollbar is not ideal"?

I personally don't really have an issue with scroll although I think they should be avoided if possible (within reason). To date the biggest complaints regarding the menu is how many actions (scroll/click) are required to access 3rd level menu items so considering that scrollbars are not ideal.

I respectfully disagree with you on this by saying the dropout menu is cumbersome when the sidebar is closed.

Once again this is not my opinion. It was I who implemented it at the time. In this case the main reason for changing was the dropout bleeding outside of the viewport on smaller screens which is valid enough. Can be fixed by not making the sidebar fixed on scroll but that's a whole other discussion.

Ultimately we are trying to find the best fit for Joomla and a solution that keeps as many people as happy as possible. So far that has had us reinventing this thing over and over which has wasted us a lot of time and effort. This is likely to go full circle and revert back to the original accordion menu. With a little luck we won't keep going around that same circle. This time I'll watch from the sidelines (",)

[frogydiak]

@ciar4n LOL! Like I said "It sucks to be you" and I agree with you to watch from the sidelines and let them decide. Hey, you guys done? So I can do my job now?

Anyways, this is just my observation since I learned and love Joomla wayback to its Mamboo days. It has always been my belief that most Joomla developers are not good with UI/UX, I said mostly not all. To me, they seems to be so good with codes but they failed on UI and they don't care with UX for as long as their component are working properly (logic/algorithm). I guess that is also the reason why a lot of people like WP (opps sorry if that is a taboo to say here :)). I believe you are a designer? Please take a look at the website of one of the core developers :) and put on a designer's hat. Let me know what you think. Don't get me wrong, it looks fine, useable no error but... you know.

My two cents, maybe it is a bad idea to ask a Coder an opinion on how the theme should look like. Maybe a collaboration with them on how to code a design but they don't get to decide how it should look like.

Thanks!

[mbabker]

Before just arbitrarily closing every issue related to sidebars in the 4.0 admin template, let me ask this question. I know from the core viewpoint we aim to remove sidebars from our extensions. HOWEVER, in the case there is an extension that would like to use some kind of sidebar or secondary navigational element within the component's view container, is this something the template is going to support (even in an implicit way, almost akin to the install from web category navigation) or is there going to be absolutely no UI or API support in core?

[laoneo]

We really need to come up with a solution for a sidebar. Current state is:

[mbabker]

It has been said elsewhere the solution is the component sidebar is being removed from the core layouts. I don't believe the question I asked in my previous post has ever been answered, because the response to that question dictates one of two things:

• The UI element won't be a supported template feature at all
• The UI element is a low priority thing because core doesn't use it

[laoneo]

I'm the wrong person to propose something as I can live with both options. All I see is the submenu code in our helper classes where we need a solution for when we stick with submenus, otherwise we can remove it.

[brianteeman]

Personally I would propose not supporting this level of menu at all - so no sidebar. I "think" the closest to the design proposal would be for this menu to be on an interstitial landing page for the component. I assume that this could be done programmatically without the extension needing to change their code.

[mbabker]

Sidebar rendering code is in the component layouts. So removing support for it requires changes in extensions. As for the interstitial landing page thing, you could use that existing data from the sidebar helper method to build the list of links, and maybe have a very generic view in some system component to default render it, but that probably should also be overridable in some way so components can create their own interstitial landing page layout.

[brianteeman]

Thats kind of what I meant

[laoneo]

Can this being closed in favor of #22587?

[akashbisht81]

The sidebar looks pretty

[brianteeman]

Thi should be closed now

[joomla-cms-bot]

Set to "closed" on behalf of @Quy by The JTracker Application at issues.joomla.org/joomla-cms/16020

[ciar4n]

Has something been decided for this component sidebar?