New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[enhancement] MODX3: Reorganize the main menu #14291

Open
Ruslan-Aleev opened this Issue Jan 17, 2019 · 24 comments

Comments

Projects
None yet
10 participants
@Ruslan-Aleev
Copy link
Contributor

Ruslan-Aleev commented Jan 17, 2019

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.

menu_info

In MODX3 we will need to think over the structure of the main menu, and reorganize the items.

@Alroniks Alroniks added this to the v3.0.0-alpha milestone Jan 17, 2019

@JoshuaLuckers

This comment has been minimized.

Copy link
Collaborator

JoshuaLuckers commented Jan 18, 2019

Related issues:

@Ruslan-Aleev

This comment has been minimized.

Copy link
Contributor Author

Ruslan-Aleev commented Feb 2, 2019

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.

  1. Content:
  • View Website" (#14291 (comment), old name "Preview Site")
  • Resource Search (#14370)
  • Remove Locks (item now in "Manage->Remove Locks")
  • Site Schedule (item now in "Manage->Reports->Site Schedule")
  • New Resource (?)
  • Resource Groups
  • Content Types
  • Import Static Resources (?)
  • Import HTML (?)

"Import Resources and HTML" perhaps will be removed from the core in the future (#14216 (comment)).
The item "New resource" is not sure whether this item is important here, because In the tree quick links will be removed, maybe it’s worth removing from the menu so that the resource is created only from one place.

  1. Media:
  • Media Browser
  • Media Sources

There are no changes.

  1. Components (old name "Extras"):
  • Installer
  • Component settings (new name, item now in "Gear->System Settings")
  • 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.

  1. Users management (new item):
  • Users (item now in "Manage->Users")
  • Access Control Lists (item now in "Gear->Access Control Lists")
  • Flush Your Permissions (item now in "Manage->Flush Your Permissions")
  • 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.

  1. Manager (new item):
  • Dashboards (item now in "Gear->Dashboards")
  • Menus (item now in "Gear->Menus")
  • Toggle language (?)
  • Contexts (?; item now in "Gear->Contexts")
  • Manager Customization (?; item now in "Gear->Manager Customization")
  • Property Sets (?; item now in "Gear->Property Sets")

This new item contains settings that help customize / change the manager panel.
The item "Toggle language" in MODX3 is now in the "User", but is not obvious.
Perhaps the item "Contexts", "Manager Customization" and "Property Sets" should be moved to the item "System", is not clear. Although these elements edit the manager panel...

Perhaps the whole "Manager" section will be part of the "System" section - #14291 (comment).

  1. User (user icon / gravatar):
  • Edit Account
  • Messages (?)
  • Logout

There is almost no change.
Question on the item "Messages", does anyone use this?

  1. System (gear icon):
  • Clear Cache / Refresh URIs (item now in "Manage->Clear Cache / Refresh URIs")
  • Component settings (item duplicated from 3); item now in "Gear->System Settings")
  • Manager Actions (?; 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")
  1. Help / Question

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?

@sottwell

This comment has been minimized.

Copy link
Contributor

sottwell commented Feb 2, 2019

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.

@sottwell

This comment has been minimized.

Copy link
Contributor

sottwell commented Feb 2, 2019

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

@Ruslan-Aleev

This comment has been minimized.

Copy link
Contributor Author

Ruslan-Aleev commented Feb 2, 2019

@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.

@rthrash

This comment has been minimized.

Copy link
Member

rthrash commented Feb 2, 2019

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.

@Ruslan-Aleev

This comment has been minimized.

Copy link
Contributor Author

Ruslan-Aleev commented Feb 2, 2019

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".

@JoshuaLuckers

This comment has been minimized.

Copy link
Collaborator

JoshuaLuckers commented Feb 2, 2019

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.

@rthrash

This comment has been minimized.

Copy link
Member

rthrash commented Feb 2, 2019

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.

@Ibochkarev

This comment has been minimized.

Copy link
Contributor

Ibochkarev commented Feb 2, 2019

I also do not use Property Sets

@Ruslan-Aleev

This comment has been minimized.

Copy link
Contributor Author

Ruslan-Aleev commented Feb 2, 2019

There are people, @opengeek and @sepiariver included, that would go to war against removing them.

Dangerous changes :)

@opengeek

This comment has been minimized.

Copy link
Member

opengeek commented Feb 2, 2019

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

@rthrash

This comment has been minimized.

Copy link
Member

rthrash commented Feb 2, 2019

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

@JoshuaLuckers

This comment has been minimized.

Copy link
Collaborator

JoshuaLuckers commented Feb 2, 2019

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.

@JoshuaLuckers

This comment has been minimized.

Copy link
Collaborator

JoshuaLuckers commented Feb 2, 2019

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.

  1. 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".
@Ruslan-Aleev

This comment has been minimized.

Copy link
Contributor Author

Ruslan-Aleev commented Feb 2, 2019

I would not change the "Content" section, from the entire menu it is the most understandable now :)

@sepiariver

This comment has been minimized.

Copy link
Member

sepiariver commented Feb 2, 2019

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 ;)

@Ruslan-Aleev

This comment has been minimized.

Copy link
Contributor Author

Ruslan-Aleev commented Feb 2, 2019

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 :)

@guyinpv

This comment has been minimized.

Copy link

guyinpv commented Feb 2, 2019

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!

@Ruslan-Aleev

This comment has been minimized.

Copy link
Contributor Author

Ruslan-Aleev commented Feb 2, 2019

@guyinpv Link already added to the site name in MODX3 - #14218

@Ibochkarev

This comment has been minimized.

Copy link
Contributor

Ibochkarev commented Feb 9, 2019

@Mark-H , I want to know your opinion on this topic #14291 (comment).

@rainbowtiger

This comment has been minimized.

Copy link

rainbowtiger commented Feb 19, 2019

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.

@opengeek

This comment has been minimized.

Copy link
Member

opengeek commented Feb 19, 2019

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.

@rainbowtiger

This comment has been minimized.

Copy link

rainbowtiger commented Feb 19, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment