revolution
revolution copied to clipboard
modxcms
[enhancement] MODX3: Reorganize the main menu
Feature request
Summary
The main menu in MODX has items that are non specific and do not give an understanding of the nested items, for example, "Manage" and the "Gear icon" on the right. Until you hover over on item - it is not clear what elements are inside.
There are also items that are connected, but located in different places, see the picture below.
In MODX3 we will need to think over the structure of the main menu, and reorganize the items.
Possible structure of the main menu in MODX3, from left to right in MODX 2.x (in MODX3 from top to bottom).
I was here trying to collect menu items based on logical connections, maybe in the future something will be added or removed. We need a discussion.
- Content:
- Clear Cache / Refresh URIs (item now in "Manage->Clear Cache / Refresh URIs")
- Remove Locks (item now in "Manage->Remove Locks")
- Resource Schedule (item now in "Manage->Reports->Site Schedule")
- Content Types
- Import Static Resources (?)
- Import HTML (?)
Moved all the items that are related to the content in the one section. Removed the menu items that are in the widget ("New resource", "Preview Site"). "Import Resources and HTML" perhaps will be removed from the core in the future (https://github.com/modxcms/revolution/issues/14216#issuecomment-449869312).
- Media:
- Media Browser
- Media Sources
There are no changes.
- Packages (old name "Extras"):
- Installer
- Packages Settings (item now in "Gear->System Settings")
- Packages Lexicons (item now in "Gear->Lexicons")
- Namespaces (item now in "Gear->Namespaces")
In MODX, the core is also a component, but which is already preinstalled. All the listed settings are related to the components (and the core, and installed from the outside), it is logical to combine them. Thats make it clear that the settings and lexicons of the package can change in the same system sections, but depending on the namespace (at the beginning of acquaintance with MODX it is not immediately clear).
- Access (new item):
- Access Control Lists (item now in "Gear->Access Control Lists")
- Resource Groups (https://github.com/modxcms/revolution/pull/14855#issuecomment-652141921)
- Flush Your Permissions (item now in "Manage->Flush Your Permissions")
- Users (item now in "Manage->Users")
- Logout All Users (item now in "Manage->Logout All Users")
All user settings will be collected in one place, now they are divided into different menu items.
- Manager (new item):
- Dashboards (item now in "Gear->Dashboards")
- Menus (item now in "Gear->Menus")
- Form Customization (item now in "Gear->Form Customization")
- Contexts (item now in "Gear->Contexts")
- Property Sets (item now in "Gear->Property Sets")
- Lexicons (item now in "Gear->Lexicons")
- Toggle language
This new item contains items that help customize / change the manager panel. The item "Toggle language" in MODX3 is now in the "User", but is not obvious.
- Profile (user icon / gravatar):
- Edit Account
- Messages (?)
- Logout
There is almost no change. Question on the item "Messages", does anyone use this?
- System (gear icon):
- Clear Cache / Refresh URIs (item now in "Manage->Clear Cache / Refresh URIs")
- System Settings (item now in "Gear->System Settings")
- Manager Log (item now in "Manage->Reports->Manager Actions")
- Error Log (item now in "Manage->Reports->Error Log")
- System Info (item now in "Manage->Reports->System Info")
Perhaps the menu item "Lexicons" and "System Settings" should be placed in the "Manager" section.
- Help / Question
It may be worth moving the section inside the "System" section.
Visually, you can test the new menu, see PR - https://github.com/modxcms/revolution/pull/14855
For all menu items, we need to specify their names and descriptions, and then some items are related by meaning, but they are not related in the names and descriptions.
@JoshuaLuckers @Jako @Mark-H @Alroniks @opengeek @rthrash Do you have any comments and suggestions?
As long as the menu is still manageable, it doesn't matter so much how it's structured, since everyone will want a different structure. What is intuitive to one person can be totally confusing to someone else. While there can be some consensus for the organization, the main feature needs to remain the ability to adjust and customize it to suit any needs.
And yes, I have used Messages along with a simple Dashboard widget to report on the active user's messages.
https://gist.github.com/sottwell/bca3dc4d2de4b15a5261
@sottwell It is not in the intuition of the case, but the essence of the elements. In the current version, for example, user elements are located at different points, see the picture above. Although everyone has their own vision, so we need a discussion :) As for the customization of the menu, I completely agree.
Great discussion; thanks for starting it. :)
“Preview Site” should just be “View Site” or “View Front-end”, which is more accurate.
I’m on the fence about a “Manager” menu, but understand the logic behind it. I’d rather see it as a submenu of a “System” or “Settings” menu.
Part of the reason for the current structure was to have fewer top-level menus for different screen sizes, and this would reverse that. We could also make an argument for the super admins (“sudo users” which bears a naming discussion itself) having a special Dashboard with a few extra buttons, like flush permissions and logout all users. Probably more. Most users of sites do not need access to these functions, and this could lead to further menu simplification.
I’m on the fence about a “Manager” menu, but understand the logic behind it. I’d rather see it as a submenu of a “System” or “Settings” menu.
Yes, we also thought about this variant.
Perhaps some elements will disappear from the core. For example, for the entire practice, I have never used "Property Sets".
The top-level menu Content is focussed around "resource" objects. It would be more logical to rename it to Resources.
“Preview Site” should just be “View Site” or “View Front-end”, which is more accurate. I agree that "Preview Site" should be named differently. Maybe it's better to name it "View Website" because "Website" is the name of the default context and is also used in the tree as root node.
In a multi context environment used to run different versions of a site (multi-language, multiple sites in 1 manager etc) the behaviour might cause confusion.
Perhaps some elements will disappear from the core. For example, for the entire practice, I have never used "Property Sets".
There are people, @opengeek and @sepiariver included, that would go to war against removing them.
There are people, @opengeek and @sepiariver included, that would go to war against removing them.
Dangerous changes :)
I also do not use Property Sets
For example, for the entire practice, I have never used "Property Sets".
https://media.giphy.com/media/WXtccLGTLB1NS/giphy.gif
I’d lobby for “pages” vs “resources”. It would be very nice to have a more intuitive platform that requires less education.
Yes, I get it that resource is the correct term, and a page does not technically connote all that a resource can do. But I’d much rather see people with fewer opportunities to be intimidated or frustrated by having to understand and explain compsci terms to colleagues.
Developers are smart enough to understand the difference. We shouldn’t, IMO, make it harder or more technical or require more extensive training for average daily site users (that likely interact in 80% or more of a site’s lifespan).
Death by 1000 cuts… lol
I also do not use Property Sets
For example, for the entire practice, I have never used "Property Sets".
https://media.giphy.com/media/WXtccLGTLB1NS/giphy.gif
To be honest I never use them either. I recently became aware of them and now I do see how useful this feature is. People should be made more aware of this powerful functionality.
I’d lobby for “pages” vs “resources”. It would be very nice to have a more intuitive platform that requires less education.
Maybe it should be named Website and contain entries that are related to managing the content of a website.
- Website (renamed from Content):
- Create new page (renamed from New Resource)
- Show publication schedule (renamed from Site Schedule)
- Show page groups (renamed from Resource Groups)
- Open website (renamed from Preview Site)
The menu items:
- Content Types
- Import Static Resources
- Import HTML are better placed under "Manage".
I would not change the "Content" section, from the entire menu it is the most understandable now :)
Property sets are one of the most powerful and differentiating features of MODX. The ability to create, and recall by name, a set of configuration options for any Element—honestly cannot fathom how anyone would not find it useful.
Resource (“page”, whatever you want to call it) Properties are similarly critical. Different in implementation—but upon consideration of the usefulness of Resource Properties, abstract that out to everything else in the system, and it’d be hard to justify killing it.
Ryan is 100% correct in that war would ensue were Property Sets to be removed!
(...and he’s missing out on the fun by not using them ;)
Guys, I did not advise removing the "Property Sets", I just gave an example that there are functions that are not used by users (for me, this is a "Property Set", apparently I do not use this functionality in vain). This is just an example, no need to delete it :)
I am a HUGE fan of not having to open a submenu just to click the link to open the front-end. This little button needs to be visible at all times throughout the Manager and open the front end in a new tab.
I would not call it "preview" as this suggests you're not seeing the real live site, but just a preview of it, which is confusing.
I understand this could be tricky if multiple domains are hosted, but you all are smart enough to figure that out! Just as long as we have instant access to open the public site at any moment in time.
The first thing I do on any MODX install is edit the menus and make the preview site link on the top level.
For other menu discussions, I have to say I don't even use the menus much. I do all my resource work with the menus and icons in the sidebar itself. But of course I will open the settings area, or go into addons area sometimes when needed. This doesn't mean I don't want the menus, but it raises the question of whether they are the primary way people find things. I worked on a site that had so many addons that the Extras menu became so long it went off screen and there was no way to see the items at the bottom. I have to zoom out the browser to get to all the items. These kinds of problems need solved too.
Almost every CMS I've tried has a dedicated place just to handle addons/extras/extensions. It could be its own button somewhere and open its own UI.
So many other menus basically boil down to nothing more than configuration/settings. I'd almost like to see everything that can be labeled a configuration to go under a single big configuration management screen, which itself could be visually split into sub-categories if needed.
Anyway, I mostly just wanted to say, put the view site link on the top!
@guyinpv Link already added to the site name in MODX3 - https://github.com/modxcms/revolution/issues/14218
@Mark-H , I want to know your opinion on this topic https://github.com/modxcms/revolution/issues/14291#issuecomment-459953084.
As for property sets, don't people create these directly in whatever element is actually using the property set? I never noticed that menu item was there because I do all the creating and editing of property sets inside the relevant element.
As for property sets, don't people create these directly in whatever element is actually using the property set? I never noticed that menu item was there because I do all the creating and editing of property sets inside the relevant element.
No. In fact, I only use Property Sets from the dedicated interface because a single set is intended to be used across multiple elements. If you only access them from a specific element, you do not get the full benefit of using Property Sets.
OK, I see your point, although you can still create a property set in one element and then use it in other ones. For all for my sites, I've never needed to use a global property set. In any case, I don't see any need to drop the Property Sets link from the menus. Since people all have different work habits and preferences, it's nice that MODX provides several different ways to edit various things.
I really like the proposed menu structure. I've been wondering a few times why certain elements are located where they are right now (which I'm sure still has a ton of thought behind it).
Is there a reason why Clear Cache is being used twice now, first under "Content" and second under "System (gear icon)"?
Another thing I want to bring into this discussion and which I think should be changed regardless of the menu structure is the naming of the respective access policy settings to those menu items. Right now there are settings described as
Show the top menu item "Site" (menu_site) Show the top menu item "Security" (menu_security)
which don't share their name with any entry in the menus. It takes me quite a bit of time whenever I have to setup new ACLs to figure out which menu items those actually address.
Is there a reason why Clear Cache is being used twice now, first under "Content" and second under "System (gear icon)"?
The cache clears both the manager panel and the site (web and mgr contexts), so I decided that duplication of these items is appropriate. Although, most likely, it is worth leaving "Clear Cache" only in the "Content" section so as not to confuse users. For a similar reason, I duplicated Packages Settings ("Gear-> System Settings") and Packages Lexicons ("Gear-> Lexicons"), because settings are relevant for both packages and the core.
Another thing I want to bring into this discussion and which I think should be changed regardless of the menu structure is the naming of the respective access policy settings to those menu items.
Yes, there are outdated names due to the old MODX structure. This requires a separate PR, there are a lot of problems with ACLs now.
Interesting, because I always add Clear Cache under the Content menu, since that seems more logical for my clients. FYI, I also rename Content to the Site, which I prefer.
I also rename Content to the Site, which I prefer.
JoshuaLuckers also suggested renaming the section to “Website” - https://github.com/modxcms/revolution/issues/14291#issuecomment-459976749, but it seems to me that the “Content” section is wider and the name “Content” is appropriate. Although the name "Site" can also be used :)