Admin Theme - Change Default Desktop Menu

[rtpHarry]

I've been working a lot with the new admin theme menu in the last week and I have to put my thoughts on record because I think it's terrible.

Apart from looking vaguely pretty it seems to just make every task harder, requiring more mouse dexterity, more mental steps, more mouse travelling.

Huge amounts of mouse travel

Most of the time, because of the large icons and the independent scrolling, I need to scroll the menu to get to the item I want to use. Naturally, this means I stop scrolling as soon as the item I'm looking for appears at the bottom of the screen.

This means the most of the time the process is: across to menu, scroll, move all the way down bottom of the screen to the icon and I have to then have to travel all the way back up to the top of the screen to pick a sub menu item.

Before it was look, move directly to item, click.

Menu scrolling independently makes it more fiddly

Logically the menu is separate from the content but in practice this doesn't offer a benefit. I am either working with content or with the menu. I find being able to scroll anywhere on the page rather more natural than having to move into the thin menu column.

It does mean the menu is always there and on long pages that can save some scrolling, but a better solution for that is to make the old style menu follow you down the page.

Jarring sub menu pop-ups while scrolling

While you're scrolling the main menu the submenus are popping up and disappearing and it's jarring. Your eye is drawn to it and it disrupts the mental flow.

Have to whip the mouse on new page load

You click a top level, big icon button and it navigates to that page. When that page loads your mouse is still over the menu item so the submenu pops up again on the new page, hiding the main page content and forcing you to whip the mouse over to the far right of the submenu to make it go away so that you can start using the page.

Worse still if you had scrolled to get your menu item, when the new page loads it could show a completely different submenu because your mouse is now over a new button. Again its disruptive and jarring as your eye is drawn to it to start off with even if you then quickly realise its not relevant.

Fiddly when travelling over to sub menu

If you get the mouse swoosh slightly wrong and go a bit more up and right (as in, the natural path from button to submenu) instead of right and up you have to go back and have another go because your submenu has now gone or turned into another sub menu.

Have to remember the sub menu items now rather than being able to scan for them in the list

A sub menu item is only put in there by the module author if they think it is a core task and something you want to get at so quickly you can't go through the normal process of going into the module main page and selecting it from there.

This new method of hiding these items means I'm thinking "Content Parts" but the new menu forces extra mental steps because I have to think "Content Parts", that's in "Content Definition", hover, ok now where is "Content Parts" in the list.

Before it was just look, click.

Conclusion

So there we go, my first orchard hate mail. I think we should seriously review its inclusion at all but if I'm alone here on this line of thinking then I would like to reopen the discussion about having a toggle setting in the admin to do an old admin style menu. And if that is also denied I will go off in a huff and make a module to override it.

The problems are all created just so that we can have some big icons and a fancy interactive submenu. It doesn't seem to solve any issue, be done out of a necessity or make the menu easier to use.

Has anyone else spent time with the new menu what wants to weigh in on their experience?

[sfmskywalker]

Such a great write up. I agree with most of your observations and sentiment, except for having to remember the sub menu items. In your example, the same is true with the old admin theme: You want to go to Content Parts, but you need to know you need to click on Content Definition first.

To solve most of these UX issues, perhaps we should do the following:

1. make the menu be part of the entire page again (this is a theme setting)

2. Use the accordion style again (which you see when you make the window small enough). This way it's more like the way it is in the old admin. Antoine did this, but we decided to stick with what comes from the box. But if more people agree the current menu style is annoying enough, I would be all for going with the accordion style.

Let's see what others think.

[rtpHarry]

Thanks :)

Ah yes you're correct, I picked a bad example there, "Content Parts" is not a submenu item on the old admin theme, but with the items that are sub-menus, they are shown by default.

[Skrypt]

Technically the accordion menu is in there.

It just appears when your screen is smaller for tablet devices. So, normally if you are using a tablet or cellphone it should be an accordion. So, since now we can have touch screens under Windows it is sure that this flyout menu makes less sense. Maybe we should always keep the menu closed like on mobile devices all the time like this :

Then we would just need to remove the styling transformation for the col-lg-x breakpoint of this menu. Because the flyout menu is simply not meant for touch devices. The accordion menu is and we can scroll it with fingers. Else, like @sfmskywalker says, we can redo what @agriffard did and display a menu on the left side if we are on desktop sizes devices. But, remember that now devices like iPad pro's have wider screens and that it would make less sense for those. We have now tablet devices that have desktop resolutions. So, I think we need to decide if this design is mobile first or desktop first.

[sebastienros]

Just one comment as I need to play more with it to say anything. About the independently scrolling menu, I remember that I was in favor of that too because this way it could "stay there" while scrolling the page. I understand now that it requires the mouse to be moved over it to scroll it, which can be a pain. I think we could have settings so that we can change some behaviors. Maybe with defaults that look like the previous theme, and tweaks for new options.

Feedback is always good, and it can start discussions, it's good to be able to get words on issues, it's easier to fix.

[Skrypt]

An option for making the sub-menu items to not always open/close when scrolling the left menu would be the regroup all the items that have sub-menu on the top of the menu and then have those that don't have on the bottom. That way we won't get that flicking sub-menu scenario.

[Skrypt]

The main reason why we have an independently scrolling menu is because of the fact that some people could have up to 40 menu items in there. So if we revert back to a menu that does'nt independently scroll we will have left menus that we will need to be scrolled all the way down too. Currently the contrib modules have total control on where it's menu items will be ; and most of modules will use a root menu item. I personnally don't think that the problem is the independently scrolling menu.

A problem that I agree on is that the Amaretti theme menu has automatically opening sub-menus and that it's been built for having non-navigation root menu items when it has a sub-menu. Orchard has root menu item navigation and that's why at first I removed the auto-opening feature of the sub-menus. That fixes one problem but that makes now another. Then if we have root menu items that opens up sub-menus only. We need to be able to have 2 different actions on the root menus that have sub-menus. One action to open the sub-menu and one for opening the default action of that root menu item. So, what should that root menu item do now as a priority? Clicking on the root menu item icon should open the sub-menu or go to it's default action route? We can't do that.

The solution would be to have non-navigation root menu items for those who have sub-menus. Which means that we now will need to put the default action inside the sub-menu as a first item in that list. Remember that I said that contrib modules have their own menu implementations. That means that some will need to make changes so that we can now access their default action if we do that.

So, fastest solution is to use an accordion style menu. Because that's what Orchard uses naturally. The other solution described would have breaking changes.

[rtpHarry]

In the weekly meeting today we agreed to move over to the mobile menu throughout:

1. Make the mobile accordion style menu the default at all screen sizes
2. Keep the old desktop menu code tucked away in case we want to go back to it
3. Add a code-based solution for first submenu item
   • When a module has submenus the top level menu button no longer is a button. It becomes a toggle to expand the submenu instead.
   • A module will now need to provide what used to be the top level item link as the first sub menu item. For example the Blog menu item is now a toggle to expand its submenu. At the top of the submenu is a Manage Blog link which points at the same place the original Blog link poined.
   • For modules that don't yet support this a menu item will be automatically created with the text "General"
4. The top level icons should be in a fixed width container so they all align their text nicely

It was discussed that @agriffard may be the person to tackle this as he did some similar work to this before but @Skrypt says that might not actually have been relevant to the new tasks so it's probably open to whoever wants to claim it.

Did I miss anything?

[Skrypt]

What @agriffard did was nice but we would then need to have 2 different CSS code base for both menus since what he did was transforming the current flyout menu into an accordion style menu. I think it will be easier, for now, to just use the current accordion menu and to only change it's breakpoint to be able to see it all the time. Unless we want an accordion menu that will be always opened on desktop sized devices. I personnally prefer having the menu hidden all the time as it saves space for the actual content.

Later on we'll provide proper fixes for the flyout menu and make it an option to the admin theme. @agriffard You can also do the accordion desktop sized menu and have it as an option. So, for now, short term goal is removing that flyout menu. If we do an accordion menu it needs to be independant of the flyout menu styles, not change them so that we can switch styling sheets by changing the admin configuration that we will add later on.

Does it make sense?

[rtpHarry]

yes I agree that the single menu should just be made visible throughout. I haven't seen @agriffard's work, I wasn't involved in the admin theme then but I'm guessing leaving the current desktop menu as untouched as possible would make it simpler to surface via a setting in the future if we went down that path.

[rtpHarry]

#2634 should either give some tips or be resolved by the plans in this thread.

[agriffard]

I updated the amaretti theme and made the changes to display an accordion menu : • Change Assets\Less\includes\config.less : @left-sidebar-width from 100px to 240px. • Change Assets\Less\includes\structure\left-sidebar.less : Move the .sidebar-elements class outside of @media @phone {} to always display the menu as an accordion. • Change Themes\TheAdmin\Views\Layout.cshtml : <div class="or-left-sidebar or-left-sidebar--click"> to open the sidebar sub menus on click, not on hover.

[sfmskywalker]

Any chance you can do this using overriding rules in our own less files, rather than changing the amaretti files?

[agriffard]

I don't really know how. The Amaretti theme is made to have a left sidebar with big icons that displays sub-menus on hover.

I tried to make the least changes required to display an accordion menu for all screen sizes.

[sfmskywalker]

Understood. I'm pushing a change that contains overriding files outside of the FoxyTheme folders so we don't have to make manual changes there when a new update comes in. The only file we need to be careful of is Layout.cshtml. At the same time, we'll never accidentally overwrite that file since it's not part of the original FoxyThemes distribution anyway. I did add a Maintenance.info file where I mention this change you made, just to be safe.