Reorganize the Admin Menu

[MikeAlhayek]

Fix #11942
Fix #12710

Legacy Mode

If you are not ready yet to update the menu in your project, you can enable the legacy format by adding this code to your startup project

AppContext.SetSwitch("LegacyAdminMenuNavigation", true);

Consolidate All Settings Under 'Settings' Menu and Replace 'Configuration' with 'Tools'

Moved the "Content definitions" menu to "Design" tab

Access Control

Settings Menu (All Features Enabled)

Tools Menu

I also moved the Workflows and Audit Trail under Tools instead of the root level.

[hishamco]

This is the first time I have seen Tools menu, where did it come from?!!

[MikeAlhayek]

Please read the referenced issue.

[hishamco]

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

No Tools mentioned there?!! BTW the link in the related issue is broken

[MikeAlhayek]

Look at the discussions. Tools is a better term to use here since we added the Settings. Do
You have an issue with Tools?

[gvkries]

I like it, but I'm not sure about moving audit trail. I think it's important enough to stay at the root.

While you are at it, do we agree to move GraphiQL to Tools, or should it go to search as requested in #12710? I think it makes sense in the new tools menu.

[gvkries]

Additionally, can we somehow group authentication and security settings? They seem to be closely related IMHO.

[MikeAlhayek]

I like it, but I'm not sure about moving audit trail. I think it's important enough to stay at the root.

This was requested by @sebastienros in one of the meetings. I prefer keeping the main menu free for users to utilize as they see fit. While the importance of features is clear, it can vary greatly from one user to another. So, why should the Audit Trail take priority over other features like Workflows, the Admin Menu, Features or Deployments?

Additionally, can we somehow group authentication and security settings? They seem to be closely related IMHO.

I do not disagree with you there and Authentication is part of security. I am just trying to not add yet another level to the depth of the menu. and is one of the reasons why I went down an alternative approach here so that the main menu is much thinner and not too deep.

[gvkries]

I like it, but I'm not sure about moving audit trail. I think it's important enough to stay at the root.

This was requested by @sebastienros in one of the meetings. I prefer keeping the main menu free for users to utilize as they see fit. While the importance of features is clear, it can vary greatly from one user to another. So, why should the Audit Trail take priority over other features like Workflows, the Admin Menu, Features or Deployments?

Additionally, can we somehow group authentication and security settings? They seem to be closely related IMHO.

I do not disagree with you there and Authentication is part of security. I am just trying to not add yet another level to the depth of the menu. and is one of the reasons why I went down an alternative approach here so that the main menu is much thinner and not too deep.

Thanks, I agree with all you said.

[MikeAlhayek]

@gvkries I moved the OpenId Connect and Authentication under Security just so we can see if the experience is acceptable or not. Feel free to checkout the branch and test driving it.

I also renamed the "Security" tab at the root level to "Access Control." This feels like a much better fit, especially since the security settings have been moved to the Settings tab. The term "Security" can often feel overused, and "Access Control" provides a clearer, more specific representation of the functionality related to users, roles, and authentication.

[Piedone]

In general, I'm OK with this.

However, I see frustration both for users (to learn and unlearn the new menu structure) and developers (basically all admin menus will need to be checked, most changed) when getting this update. Documentation needs to be updated all over the place as well. All of these are subtle breaking changes one will only discover when bumping into an issue or users complaining, not instantly clear like a build error.

I don't know how to make this easier. For sure it starts with documenting it, and providing a search & replace pattern for the simple case of Configuration -> Settings, so you can at least quickly fix that in the codebase.

[MikeAlhayek]

Once we all agree on the new menu, I'll update the documentation and add release notes updates. We'll probably talk more about it during triage tomorrow.

I do agree it's going to require every project to change. But the good news that it's part of 3.0 :)

[sebastienros]

If we could not screw users for some time that would be great. There are breaking changes that don't break anyone or are super natural to fix ([Obsolete] with what to do instead) and breaking changes that really suck because they seem like unnecessary small changes and impact lots of installs.

But the good news that it's part of 3.0 :)

This doesn't sound good. It's not because we had to ship some breaking changes that we can add any other ones. Every breaking change should be done with measure.

[MikeAlhayek]

@sebastienros We could complicate things and introduce a switch to keep old behavior. But if we do that, the code will double as we'll need to check the switch and either load old menu or old menu.

Alternatively, we could create a second menu "admin" and "admin-new" so if the user want to stay with prior state, then we would load admin-new instead of "admin"

[gvkries]

I've tried this out and I love it :-)

Some things I would like to mention:

• Features: I've expected this in Settings first, but it kind of makes more sense in tools. Might need to get used to it, because it was configuration before.
• As noted above in a comment, I would stick with the existing title casing. I find that more compelling.
• Keeping tools and settings at the end makes sense for me. E.g. moving multi-tenancy up.

Thanks @MikeAlhayek

[Piedone]

#17112 (comment) brings up a larger issue: the majority of this structuring is opinionated and not at all clear to multiple people in the same way. I'm afraid we'll go circles here, and the end result won't make more people happy than where we started.

[MikeAlhayek]

#17112 (comment) brings up a larger issue: the majority of this structuring is opinionated and not at all clear to multiple people in the same way. I'm afraid we'll go circles here, and the end result won't make more people happy than where we started.

Everything that we have today about the UI is opinionated. I am not sure there is a new issue.

[Piedone]

The new issue is that the current menu is already out there, and has been for a long time, while this PR moves things around, forcing everyone, developers and users alike, to adapt, and in a significant way. Our conversations in the various comment threads and otherwise show that this is not at all a clear matter, and thus we'll change the current opinion with a different opinion, thinking that it'll be better, but ultimately not having much to back it. UX is not a hard science, but it can still be more methodical than developers sharing their opinions. And in such a case, the status quo wins, because it doesn't need everyone to put work into it.

I don't think we should change the menu after conversing just among ourselves. I know, and commend, that you've asked for wider feedback, but us not getting any doesn't mean that most people will be happy with the result. I see no point in arguing among ourselves further about things like whether something is a tool or a setting. Perhaps we're the worst people for this, actually, since it has been very long since we needed to find something in the menu without having a clue, or without understanding the fundamentals.

So, taking a step back, I propose rethinking the admin experience, something that's not a new idea by far: with the help of a UX professional (I have ideas on how to find them and Lombiq can fund their work), do the following:

1. Find a suitable open-source Boostrap dashboard theme/template as a base. We'll need to build a somewhat custom admin story, but not from the ground up.
2. Figure out the basic Orchard Core-specific UI principles the admin should follow.
3. Update a single UI to be our perfect role model (like the basic content item editor), and the menu structure. The rest of the UI will be kept more or less as-is, but with updated common visuals (coming from the theme) and quick wins (e.g. common pieces like buttons, hints, labels, fields, will all be updated just by updating the common classes, or with search and replace).
4. Release it as part of a major version. In the future, perhaps, maybe, follow the role model in all existing UI, and definitely in new UI. But whatever we'll have will be good enough.

BTW @BenedekFarkas re #11942 (comment): I thought about menu item favoriting too. It's perhaps something that an existing template can offer, but if not, it's not a big deal to implement.

[MikeAlhayek]

@Piedone At this point, don't you think restarting the process might be too late, given the significant time we've already spent discussing it across various platforms?

If you have the time to consult a UI expert to guide the menu structure, I'm all for it. However, I also want to avoid letting this PR sit for too long, especially considering the amount of time and effort already invested by everyone, including yourself.

The current structure in this PR reflects the efforts to incorporate all the feedback we've received, aiming to create a solution that works for the majority.

[Piedone]

Despite the time spent, no, at this point I wouldn't merge this: the changes are disruptive, so we better be sure of it, lest we have to repeat it.

[MikeAlhayek]

the changes are disruptive

Its not. We already provide a backward compatible (legacy mode).

the changes are disruptive, so we better be sure of it, lest we have to repeat it.

Is there a timeline on when you'll have a UX expert look at this and provide us feedback?

[Piedone]

It's disruptive because while you can switch back temporarily, we surely won't maintain two menus forever. At that point, it'll still come at once, it's not something gradual, just optionally delayed.

I don't see much point in moving around the menu in itself, because we're missing the forest from the trees: What we need is a path to improve the admin experience, coherently and with guiding principles, not small pieces of it in isolation and without an overarching plan. Nobody will be able to help us with just the menu, without thinking through the whole thing: we might be better off with a different structure of the admin area, to begin with, perhaps with other ways of navigation as well, even secondary as you previously suggested, or whatever else.

This will take months, but we'll have something for the long-term. If we want to try this approach, I can look into finding a suitable UX person now, and with the holidays I'd guess start this in earnest mid-January.

[MikeAlhayek]

It's disruptive because while you can switch back temporarily

It's temporary if we decide it going to be temporary. It could be a long term or permanent placement.

I don't see much point in moving around the menu in itself, because we're missing the forest from the trees

While you don't, I and many other see the point.

This will take months, but we'll have something for the long-term. If we want to try this approach, I can look into finding a suitable UX person now, and with the holidays I'd guess start this in earnest mid-January.

I feel that you are purposely trying to complicating this just because you don't seem to agree with the request.

The request is coming from many feedback I personally get. And others, tested it and seem to be happier with it.

Anyway, will talk more about this during the next meeting, hopefully you can join.

[Piedone]

I also told in the very beginning that:

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.

I'm still suggesting the same.

It's not that I merely disagree (I personally actually agree with almost all the changes here, as you've seen); rather, I'm of the viewpoint that these changes, in this form, aren't a net benefit to OC itself and the wider ecosystem.

[MikeAlhayek]

I'm still suggesting the same.

I understand. But, unless you are willing to find a consultant to provide us with their opinion, no one will. We already tried to ping the community to get as much feedback as possible. I internally consulted the end users "not developers" as well. So we have been following your suggestion all along and the current state of the PR seems to be accepted by folks other than me like @sebastienros @gvkries and other community members and internal end users.

[Piedone]

I am willing, that's what I told above, and Lombiq will fund it.

What was the feedback those internal end users had to share about the current menu?

[MikeAlhayek]

I am willing, that's what I told above, and Lombiq will fund it.

Can't wait to hear what feedback we get back. Please update us on the process. Hopefully it won't be long time before your consultant some back with some feedback.

What was the feedback those internal end users had to share about the current menu?

They love the current state. They said the menu is much easier to navigate and find what they are looking for. I incorporated the feedback previously which was mainly around settings.

[Piedone]

From the meeting today:

• I'll update the community about where the initial discussion with UX people go; I've sent out a couple of e-mails and submitted an ad to https://opensourcedesign.net/jobs/. As we talked about, the revamp of the admin area would be a long and painful process. I think it is necessary, though, and more importantly, to have an organized instead of an ad-hoc approach to building the admin UI.
• As for this PR, while I uphold the viewpoint elaborated above, I won't go against the vote of the majority.

[MikeAlhayek]

@Piedone thank you.

I’d suggest opening a separate issue for the admin theme overhaul so we can dive into that more specifically and keep track of actionable items there. Anything related to the admin menu can stay in this PR so we don’t mix too many things up, especially since this PR is just focused on one part of the overall UX.

[Piedone]

Follow-up issue: #17327.

[gvkries]

What about making this opt-in for now and maybe switch that later on (still to decide). This way we don't lose this great work and we can still change it, whenever there is some conclusion about the admin portal at all.

[MikeAlhayek]

What about making this opt-in for now and maybe switch that later on (still to decide). This way we don't lose this great work and we can still change it, whenever there is some conclusion about the admin portal at all.

@gvkries I honestly think this should be merged as-is then worry about completing the admin portal idea whenever that is concluded and not muddy the water with two different initiatives.

[gvkries]

@gvkries I honestly think this should be merged as-is then worry about completing the admin portal idea whenever that is concluded and not muddy the water with two different initiatives.

I agree with you, I just thought that we could accommodate others by making this optional for the time being :)

[MikeAlhayek]

we could accommodate others

We already did when adding this AppContext.SetSwitch("LegacyAdminMenuNavigation", true);

By making this the default option tells everyone this is the way forward. Anyone is just starting to use OC will get used to the new way. Anyone that wants to stick with the legacy mode, they can set it in their own project when they upgrade to 3.0. But I think the legacy-mode should be supported for a very long time (or at least until the new portal is completed).

@Piedone stated if the majority want to merge it, go ahead. I am not sure what that means but I think if we get couple more approvals, I think we should merge it as-is.

[Piedone]

It means I'm neither approving nor disapproving, up to you.

[pourdelir]

I am not a professional developer, althogh I have IT backgrounf.
I am an enduser in this case. I quiet liked Orchard, however, it is very confusing to set it up. the installation was straigt forward. I need more examples and trainings to get the job done.