Move all settings menu items under Configuration > Settings menu

[MikeAlhayek]

Is your feature request related to a problem? Please describe.

Currently, site settings provided by modules are scattered on the menu in many places. Form user experience, it would be nice to place all settings under one dedicated location on the menu for easy of access and quickly know where are all the settings located.

Also, the text style on the menu items isn’t unified.

Describe the solution you'd like

Move any site setting or configurations under the “Configuration > Settings” menu

Additionally, we may want to unify the naming by using a common style. Either a title case or sentence case for every menu item. I think using sentence style will look good on the menu item as per the recommendation here

Here is how the new menu structure may look like

Configuration > Settings > Search
Configuration > Settings > Security > User login
Configuration > Settings > Security > User change email
Configuration > Settings > Security > User registration
Configuration > Settings > Security > User reset password
Configuration > Settings > Security > Security header
Configuration > Settings > Security > HTTPS
Configuration > Settings > Security > CORS
Configuration > Settings > Security > reCaptcha
Configuration > Settings > Security > OpenID Connect > Authentication client
Configuration > Settings > Security > OpenID Connect > Authorization server
Configuration > Settings > Security > OpenID Connect > Token validation
Configuration > Settings > Security > OpenID Connect > Management
Configuration > Settings > Security > Authentication > Facebook
Configuration > Settings > Security > Authentication > Twitter
Configuration > Settings > Security > Authentication > GitHub
Configuration > Settings > Security > Authentication > Google
Configuration > Settings > Security > Authentication > Microsoft
Configuration > Settings > Security > Authentication > Azure Active Directory

[sebastienros]

Needs some discussion, the current menu organization was discussed and designed this way.

[MikeAlhayek]

@sebastienros sounds good. I just think centralizing settings related items into one place will make the UI easier to navigate. For anyone looking for settings, they are always in the same place.

[Skrypt]

I kind of agree with him that "Security --> User / Roles" should be separated from the "Configuration --> Security" settings. Makes sense to me to be able to quickly find an admin UI to manage users/roles but having all the settings in there is not necessary. We don't need to access these settings most of the time.

[ns8482e]

IMHO - end user looking Configuration menu they tend to think configuring site in terms of general setting related to the site
and Setting of each vertical functional group to have its own settings i.e. what we have today Security -> Settings

Also having more than 2 level of menus are annoying and not good UI experience

[hishamco]

Also having more than 2 level of menus are annoying and not good UI experience

Could you please add anything related to UI/UX to the related issue to mak it easier for tracking

[Skrypt]

@ns8482e I agree with you also. Maybe that's the compromise that has been done so that we don't have too many levels of sub-menus. Either way, I don't think it is currently causing any issue as everything is accessible.

[MikeAlhayek]

@Skrypt @ns8482e may be we can create a new menu in the root called "Settings" which will be under "Configurations" or drop "Settings" level altogether and list all settings directly under "Configurations"

I think it is a MUCH better user experience to group all settings/configurations under the same node. IMO, placing all settings in one place removes the guessing from the user experience. Settings are not always accessed and should be a second class citizens but should be grouped.

[sebastienros]

Let's find the meeting where we discussed about Configuration vs Setting menu items. And when these items were first introduced.

[MikeAlhayek]

@sebastienros were you able to find the meeting?

[MikeAlhayek]

@sebastienros @Piedone I think we should revisit this old request. I think it is still a valid issue. We should move all the settings into one central place instead of having it all over the place.

[Piedone]

We can talk about this at tomorrow's meeting.

While I'm in favor of cleaning up the admin menu, only keeping in mind the following:

• We should have as few levels as possible while balancing it with having as few menu items on each level as possible.
• We should avoid using both "configuration" and "settings" because these are synonyms.
• We should go outside of the circle of a few core maintainers and see what users say. Perhaps also ask some UX person and see what other systems do.
• Whatever we do, we should only do it for v3. Changing menu item labels necessitates localization, which while not technically breaking, still something outside of "I update and everything just keeps working". It's also annoying to learn a new menu structure. And if you're a module author, you may notice that suddenly your module's menu items are in a very different context.

All that being said, I'm for having topic-oriented top-level menu items (like Content, Search, Security) in contrast to moving all configuration-related items under a separate menu. WordPress seems to be doing the "all settings under one menu" approach, Umbraco more of a mixed one. BTW I like the Tools menu from WP:

A lot of stuff we have under Configuration currently is really tooling.

[MikeAlhayek]

@Piedone I agree this would have to be in a major release as people will need to adjust their menu accordingly. I also agree that we should reduce the levels of the menu.

I think Design should be replaced with Appearance. And "Tools" would be a better option that "Configuration"

We'll talk more about this tomorrow and if we all agree, we'll tag this issue with 3.0 and then put the agreed menu structure here so it can be done when working on 3.0

[MikeAlhayek]

Here is a prototype of moving the settings into their own menu away from the main menu. With this prototype, we achive

• Less menu items being adding on every page admin request
• Less menu levels
• More focused menu on the site navigation while having a settings focused menu.
• We can add a settings icon on the top navbar that would take the user to the site settings if we don't want to have it on the settings.
• Adding Tools menu may be a better term to use than "Configuration".

This prototype can be found on this branch https://github.com/OrchardCMS/OrchardCore/tree/ma/rearrange-admin-menu

[Piedone]

To add here too what I told on the meeting yesterday: I'm against having tertiary navigation (besides the main menu on the left and the editor tabs). I'd start this issue by having a separate Tools and Configuration (or Settings) menu and move all the non-config features from the current Configuration menu (Import/Export, Recipes, GraphiQL, perhaps also Tasks) to Tools.

[MikeAlhayek]

Here some of the apps that have a dedicated menu for settings

Microsoft Outlook

Shopify

Discord

[MikeAlhayek]

Updated screenshots with settings search and moving the settings to the top level of the menu.

Search

[gvkries]

I would absolutely appreciate having all settings in a single spot. That is the only thing I find necessary, the other improvements like a "Tools" menu are nice to have IMHO. Regarding the new menu on the right, I understand Mikes reasoning, but I don't think it is required.

But can't we allow editing existing menu items with the admin menu feature? This way, everyone can create their own preferred structure ;-)

[MikeAlhayek]

Regarding the new menu on the right, I understand Mikes reasoning, but I don't think it is required.

You are right, it's not required. We can just put all the settings into one tab and keep the main menu busy. But, do you see a better user experience by create one site navigation focus menu and another settings focus menu?

[gvkries]

I'm not an UX expert, but personally I can see advantages of a separate settings menu on the left. This doesn't really introduce a new UI concept, but makes the main menu smaller and more focused for tasks used more often. But again, I don't think this is something that has such a big impact and given the push back from others, I don't think we should continue pursuing it.

[Piedone]

Another aspect to consider is the collapsed menu, which is especially important on smaller screens:

[domonkosgabor]

Discussion about this issue from this week's podcast: https://youtu.be/i1dEWzKl2pw?si=uHucNH1_4XuvThrE&t=1586

[MikeAlhayek]

Another aspect to consider is the collapsed menu

Another reason why we should try to keep the left menu focused and have less menu items (all settings). Less items in the main menu will make navigation much simpler of small devices and large once too.

[BenedekFarkas]

I know I'm a bit late to the party, but wanted to throw in some general lines of thought that I hope will be useful:

• Given the initial issue description, it seems like the PR blew up in complexity quite a bit - that's a sign that the issue should be split up into parts or that we should step back and have an overarching discussion about these changes before anything is implemented.
• When it comes to refactoring and/or breaking changes, there are some crucial questions to ask ourselves beforehand:
  • Is this a problem that affect users on a regular basis?
  • Is this problem widespread enough that it compensates for the breaking change it causes to everyone?
  • If not, can we offer a workaround or alternative solution that doesn't affect anyone negatively, while mitigating the original problem to a sufficient extent?

When I describe Orchard to someone new I usually include a remark along the lines of "it's by made by developers for mostly developers". Orchard has a nice UI, but it's not tailored/focusing on simplicity and ease of use for everyday users, more like developers or at least people with some technology inclination. IMO that makes it especially difficult to figure out the best way forward with UI changes, even for a UX expert, because we don't really have sufficiently large feedback or usage metrics to find a good common ground.

Side note, I just realized by reading the initial description again that I find "Settings" being a child of "Configuration" a bit weird, at least in my head they're more like synonyms.

In any case, if the motivation here to make the navigation better and more user friendly, I'd rather see one or more of these additional features (in ascending order of complexity, but 1 and 2 are fairly close to each other):

1. Search box at the top of the navigation.
2. Ability to add navigation items (or the "pages" the represent) to a list of favorites (saved in local storage) that is listed at the top in a collapsible list.
3. Add the ability to reorganize the whole navigation and store it in local storage or the User document. This way we can have a "good enough" baseline and then users can do whatever they prefer from that point onwards. Of course, there's tons of details to a feature like this, for now it's just a high-level idea.

[agriffard]

1. Search box at the top of the navigation.

There is a setting in the admin that enables a simple menu search box at the top of the navigation.

[BenedekFarkas]

Ooops, thanks @agriffard, I remembered wrong about it being only in O1. :D

[MikeAlhayek]

When I describe Orchard to someone new I usually include a remark along the lines of "it's by made by developers for mostly developers". Orchard has a nice UI, but it's not tailored/focusing on simplicity and ease of use for everyday users, more like developers or at least people with some technology inclination.

Perhaps if your sales pitch changes, OC will be used by more people. Lots of changes we have made to the UI to try to make it more user friendly. OC is great for developers, but should also be great for everyday users. At the end of the day, developers produce products that is used for people including the back-end. Most of the apps that I ship are back end deliver system for users. The more user friendly OC is, the more people will adopt it.

About 2 & 3, you may be interested in contributing into this issue #17193

This issue have involved so much discussion between thread like this and during Triage and Steering meeting. We collected so much feedback and tried to fit most feedback into one outcome. We even went the extra mile in the PR to provide a legacy mode to allow users to temporary opt-out of this change so they can update.