This goes out to some maintainers, specifically related to - Notifications / Messaging - Organic Groups - Panels Those and related/dependent modules are implementing top-level menu items, e.g. - admin/messaging - admin/og - admin/panels in the style of Drupal 4.7, instead of using the new administrative categories and structure we have since Drupal 5.x. This is not only confusing, but also clutters the administrative interface - especially, if Administration menu module is installed. I see no reason why it needs to be this way. Clearly, for example, Organic Groups and Panels are both tools to build a Drupal site -- the proper location would thus be below "Site building". In the special case of Notifications/Messaging, the situation gets even worse: It mixes administrative items for different purposes into one top-level item, meaning that permanent site configuration settings and continuously required administrative functions are located in one, bloated container with no clear distinction. Furthermore, granting administrative users the permission to administer user subscriptions will expose a new top-level menu item "Notifications & Messaging" to them -- the proper location for managing user subscriptions would be below "User management". Unfortunately, my request for changing this in Notifications was immediately won't fixed [1], which is why I see the need for a broader community consensus. I know that a change like this could probably only done in upcoming major versions of all affected modules. If the only thing that prevents this from changing are patches, then I'll happily submit some. Thanks, Daniel [1] http://drupal.org/node/366489
+100 on these comments There are many other modules that are badly classified making them hard to find. Every maintainer should take a quick look at where their modules wind up and fix them. After all it is in your best interest. If they can't be found they won't be used. -----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Daniel F. Kudwien Sent: Sunday, February 01, 2009 12:17 PM To: development@drupal.org Subject: [development] Remove top-level admin menu items This goes out to some maintainers, specifically related to - Notifications / Messaging - Organic Groups - Panels Those and related/dependent modules are implementing top-level menu items, e.g. - admin/messaging - admin/og - admin/panels in the style of Drupal 4.7, instead of using the new administrative categories and structure we have since Drupal 5.x. This is not only confusing, but also clutters the administrative interface - especially, if Administration menu module is installed. I see no reason why it needs to be this way. Clearly, for example, Organic Groups and Panels are both tools to build a Drupal site -- the proper location would thus be below "Site building". In the special case of Notifications/Messaging, the situation gets even worse: It mixes administrative items for different purposes into one top-level item, meaning that permanent site configuration settings and continuously required administrative functions are located in one, bloated container with no clear distinction. Furthermore, granting administrative users the permission to administer user subscriptions will expose a new top-level menu item "Notifications & Messaging" to them -- the proper location for managing user subscriptions would be below "User management". Unfortunately, my request for changing this in Notifications was immediately won't fixed [1], which is why I see the need for a broader community consensus. I know that a change like this could probably only done in upcoming major versions of all affected modules. If the only thing that prevents this from changing are patches, then I'll happily submit some. Thanks, Daniel [1] http://drupal.org/node/366489
Quoting Walt Daniels <wdlists@optonline.net>:
+100 on these comments
There are many other modules that are badly classified making them hard to find. Every maintainer should take a quick look at where their modules wind up and fix them. After all it is in your best interest. If they can't be found they won't be used.
And if you find one that is annoying open a bug issue in the issue queue of the project. I usually prefer the admin/by-module UI if I'm concerned with administration of one particular module. I also create an Administration menu and rearrange the menu items to my liking. So, regardless of who does what, I use the dynamic menu to suit my needs. -- Earnie http://r-feed.com Make a Drupal difference and review core patches. -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
This brings up a related issue, namely translating the name you see on the module screen to the module name and the project name. Pet peave, a module whose purpose is to add a new field type to CCK but doesn't have CCK in its name and doesn't come up in the group of CCK stuff on the Update status screen. -----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Earnie Boyd Sent: Monday, February 02, 2009 8:54 AM To: development@drupal.org Subject: Re: [development] Remove top-level admin menu items Quoting Walt Daniels <wdlists@optonline.net>:
+100 on these comments
There are many other modules that are badly classified making them hard to find. Every maintainer should take a quick look at where their modules wind up and fix them. After all it is in your best interest. If they can't be found they won't be used.
And if you find one that is annoying open a bug issue in the issue queue of the project. I usually prefer the admin/by-module UI if I'm concerned with administration of one particular module. I also create an Administration menu and rearrange the menu items to my liking. So, regardless of who does what, I use the dynamic menu to suit my needs. -- Earnie http://r-feed.com Make a Drupal difference and review core patches. -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
100% Agreed. Another module I would lump into this category is Embedded Media Field. EMF has its configuration under Content Management when it is clearly entirely configuration. So much so that the menu link item is actually named "Embedded Media Field configuration". -- Alan On Sun, Feb 1, 2009 at 12:17, Daniel F. Kudwien <news@unleashedmind.com> wrote:
This goes out to some maintainers, specifically related to
- Notifications / Messaging - Organic Groups - Panels
Those and related/dependent modules are implementing top-level menu items, e.g.
- admin/messaging - admin/og - admin/panels
in the style of Drupal 4.7, instead of using the new administrative categories and structure we have since Drupal 5.x. This is not only confusing, but also clutters the administrative interface - especially, if Administration menu module is installed.
I see no reason why it needs to be this way. Clearly, for example, Organic Groups and Panels are both tools to build a Drupal site -- the proper location would thus be below "Site building".
In the special case of Notifications/Messaging, the situation gets even worse: It mixes administrative items for different purposes into one top-level item, meaning that permanent site configuration settings and continuously required administrative functions are located in one, bloated container with no clear distinction. Furthermore, granting administrative users the permission to administer user subscriptions will expose a new top-level menu item "Notifications & Messaging" to them -- the proper location for managing user subscriptions would be below "User management".
Unfortunately, my request for changing this in Notifications was immediately won't fixed [1], which is why I see the need for a broader community consensus. I know that a change like this could probably only done in upcoming major versions of all affected modules.
If the only thing that prevents this from changing are patches, then I'll happily submit some.
Thanks, Daniel
What to do when the Admin menu gets too long under configuration? Small fonts of course, one option, but these bespectacled eyes have a tough time seeing them. Margie On Sun, Feb 1, 2009 at 1:58 PM, dragonwize <dragonwize@gmail.com> wrote:
100% Agreed. Another module I would lump into this category is Embedded Media Field. EMF has its configuration under Content Management when it is clearly entirely configuration. So much so that the menu link item is actually named "Embedded Media Field configuration".
-- Alan
On Sun, Feb 1, 2009 at 12:17, Daniel F. Kudwien <news@unleashedmind.com> wrote:
This goes out to some maintainers, specifically related to
- Notifications / Messaging - Organic Groups - Panels
Those and related/dependent modules are implementing top-level menu items, e.g.
- admin/messaging - admin/og - admin/panels
in the style of Drupal 4.7, instead of using the new administrative categories and structure we have since Drupal 5.x. This is not only confusing, but also clutters the administrative interface - especially, if Administration menu module is installed.
I see no reason why it needs to be this way. Clearly, for example, Organic Groups and Panels are both tools to build a Drupal site -- the proper location would thus be below "Site building".
In the special case of Notifications/Messaging, the situation gets even worse: It mixes administrative items for different purposes into one top-level item, meaning that permanent site configuration settings and continuously required administrative functions are located in one, bloated container with no clear distinction. Furthermore, granting administrative users the permission to administer user subscriptions will expose a new top-level menu item "Notifications & Messaging" to them -- the proper location for managing user subscriptions would be below "User management".
Unfortunately, my request for changing this in Notifications was immediately won't fixed [1], which is why I see the need for a broader community consensus. I know that a change like this could probably only done in upcoming major versions of all affected modules.
If the only thing that prevents this from changing are patches, then I'll happily submit some.
Thanks, Daniel
I don't think this applies to any of the modules I maintain, but if you open an issue on mine, I will definitely consider it. Nancy E. Wichmann, PMP Injustice anywhere is a threat to justice everywhere. - Martin L. King, Jr. No virus found in this outgoing message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.10.16/1928 - Release Date: 1/31/2009 8:03 PM
Daniel F. Kudwien wrote:
This goes out to some maintainers, specifically related to
- Notifications / Messaging - Organic Groups - Panels
Those and related/dependent modules are implementing top-level menu items, e.g.
- admin/messaging - admin/og - admin/panels
in the style of Drupal 4.7, instead of using the new administrative categories and structure we have since Drupal 5.x. This is not only confusing, but also clutters the administrative interface - especially, if Administration menu module is installed.
I, uh, actually am kind of offended at this line, because I actually did most of the work on the patch to create the new admin system and set it up in this manner. Opening with this actually made me inclined to just ignore the thread entirely but because of who you are, you get an answer anyway. But sincerely, this is *not* in the style of 4.7: 1) Panels implements everything necessary to have a block in the new admin system, including the descriptions and functions below it. 2) Panels has several administrative options that, in the normal system, would be kind of scattered and difficult to find. I know this because I originally had set things up that way, and it was frustrating. 3) Panels has a modular nature and keeps getting items added, which would be even more frustrating. 4) Keeping things together would force Panels down to admin/site-building/panels/* -- 4 levels down before it actually gets any information in the URL for itself leaves only 3 more path items before you hit the argument limits in the menu system. And worse, you now have an extra click needed to get to every Panels item, relegating it to a second class administrative system.
I see no reason why it needs to be this way. Clearly, for example, Organic Groups and Panels are both tools to build a Drupal site -- the proper location would thus be below "Site building".
I see no reason why admin_menu can't just cope with this the same way the menu system does.
To me the true nature of Daniel's request is not really about admin_menu. The placement of menu items affects all of our sites. Because of this we need some kind of standard that we can hold modules to. Because of our great menu system we can choose to move menu items to where we would personally like them on our own site. However, we still need to hold the default position to some kind of standard. If the only reason for moving to the higher level is personal preference of how may levels you have to go then it should be placed by default in the standard configuration and can be moved by all those that use it enough that they would like it at a higher level. The argument limit could be an issue, maybe we need to consider upping that limit. But I think that the vast majority of modules do not have non-dynamic argument handling that would prevent the menu item from functioning when moved. -- Alan
I, uh, actually am kind of offended at this line, because I actually did most of the work on the patch to create the new admin system and set it up in this manner. Opening with this actually made me inclined to just ignore the thread entirely but because of who you are, you get an answer anyway. But sincerely, this is *not* in the style of 4.7: 1) Panels implements everything necessary to have a block in the new admin system, including the descriptions and functions below it. 2) Panels has several administrative options that, in the normal system, would be kind of scattered and difficult to find. I know this because I originally had set things up that way, and it was frustrating. 3) Panels has a modular nature and keeps getting items added, which would be even more frustrating. 4) Keeping things together would force Panels down to admin/site-building/panels/* -- 4 levels down before it actually gets any information in the URL for itself leaves only 3 more path items before you hit the argument limits in the menu system. And worse, you now have an extra click needed to get to every Panels item, relegating it to a second class administrative system.
dragonwize wrote:
To me the true nature of Daniel's request is not really about admin_menu. The placement of menu items affects all of our sites. Because of this we need some kind of standard that we can hold modules to.
Because of our great menu system we can choose to move menu items to where we would personally like them on our own site. However, we still need to hold the default position to some kind of standard.
I honestly felt like I established and held to some kind of standard with this system.
If the only reason for moving to the higher level is personal preference of how may levels you have to go then it should be placed by default in the standard configuration and can be moved by all those that use it enough that they would like it at a higher level.
If the only reason for disliking my choices of administration, you're also welcome not to use the module. I gave several reasons why it is the way it is, and it wasn't personal preference.
Earl, I was trying to be amenable but I failed horribly. I am sorry for that. My statements were never directed at you but at the conversation in general. If Panels is the exception for valid reasons, than I am perfectly ok with that. There is rarely a standard that doesn't have a few exceptions. You a good developer and by the fact that you have other modules including Views which do not break with the norm I would say you probably have very good reasons for doing so. However, many modules do not give it such thought and I believe that is where the meat of this thread lies. -- Alan On Mon, Feb 2, 2009 at 01:13, Earl Miles wrote:
dragonwize wrote:
To me the true nature of Daniel's request is not really about admin_menu. The placement of menu items affects all of our sites. Because of this we need some kind of standard that we can hold modules to.
Because of our great menu system we can choose to move menu items to where we would personally like them on our own site. However, we still need to hold the default position to some kind of standard.
I honestly felt like I established and held to some kind of standard with this system.
If the only reason for moving to the higher level is personal preference of how may levels you have to go then it should be placed by default in the standard configuration and can be moved by all those that use it enough that they would like it at a higher level.
If the only reason for disliking my choices of administration, you're also welcome not to use the module. I gave several reasons why it is the way it is, and it wasn't personal preference.
It's not related to contributed modules so much, but I'd actually like to see us have more top level admin sections rather than less - the current split between content, building, reports, users and configuration doesn't really work out in practice. Several core menu items are mis-placed - 'post settings' in content, and simpletest in site building, for example. So while there may well be contrib modules which are abusing this (and I definitely think panels /doesn't/ abuse it), core could do a lot better to provide homes for some of these menu items. See http://drupal.org/node/228236 for the core issue dealing with this. Nat
I strongly disagree with this proposal because: (And btw I'm the maintainer of Messaging and Notifications mentioned below) 1. For complex packages, scattered pages around the admin interface really make it difficult for users to grasp the whole set of options sometimes needed to set them up. 2. The 'per module' option is no replacement for some grouping as this is a 'code oriented' concept but not a user friendly one at all. In this case, Messaging & Notifications can be a dozen modules, this won't help at all. So, unless we have in D7 some 'Per package' tab for the admin UI, that would make more sense from a usability perspective than the 'per module' idea, I'm afraid these modules' admin UI will stay the same. That said, I think guidelines are fine, so if you want to set up this one as a guideline and find some consensus, ok. But enforcing guidelines upon module maintainers, when they think they have a specific reason to skip this one or this other guideline is bad (and mostly a waste of time). So thanks for the heads up, I appreciate it, but really the reasons to keep the admin menu as it is are stated on the issue, which I'm afraid will stay as 'won't fix'... It is here, btw, http://drupal.org/node/366489 (not that I want to spend more time on this one) Jose Daniel F. Kudwien wrote:
This goes out to some maintainers, specifically related to
- Notifications / Messaging - Organic Groups - Panels
Those and related/dependent modules are implementing top-level menu items, e.g.
- admin/messaging - admin/og - admin/panels
in the style of Drupal 4.7, instead of using the new administrative categories and structure we have since Drupal 5.x. This is not only confusing, but also clutters the administrative interface - especially, if Administration menu module is installed.
I see no reason why it needs to be this way. Clearly, for example, Organic Groups and Panels are both tools to build a Drupal site -- the proper location would thus be below "Site building".
In the special case of Notifications/Messaging, the situation gets even worse: It mixes administrative items for different purposes into one top-level item, meaning that permanent site configuration settings and continuously required administrative functions are located in one, bloated container with no clear distinction. Furthermore, granting administrative users the permission to administer user subscriptions will expose a new top-level menu item "Notifications & Messaging" to them -- the proper location for managing user subscriptions would be below "User management".
Unfortunately, my request for changing this in Notifications was immediately won't fixed [1], which is why I see the need for a broader community consensus. I know that a change like this could probably only done in upcoming major versions of all affected modules.
If the only thing that prevents this from changing are patches, then I'll happily submit some.
Thanks, Daniel
On Mon, Feb 2, 2009 at 10:35 AM, Jose A. Reyero <drupal@reyero.net> wrote:
That said, I think guidelines are fine, so if you want to set up this one as a guideline and find some consensus, ok. But enforcing guidelines upon module maintainers, when they think they have a specific reason to skip this one or this other guideline is bad (and mostly a waste of time).
I agree with Jose here. A UI guideline that I've heard about grouping items. * If a group is bigger than 12 consider splitting it * If a group is smaller than 5 consider merging it into another Obviously there has to be room for some compromises, but this provides a basic concept that we can apply to lots of areas like items in menus and the "Package" names at Admin > Site building > Modules (package names with only 1 or 2 items in the package area waste of fieldset). On a default site the "Site configuration" area begins at 14 items. Any proposal that pushes more items there immediately finds itself in violation of the guideline. Similarly, a module without many extension modules has no business creating packages nor creating top level menu items. If we look at the modules that started this thread: - Notifications / Messaging - Organic Groups - Panels On a typical site I think it's reasonable to assume that these modules will be installed alongside other modules that extend them and therefore they should provide their own top level navigation. More specifically: -Notifications / Messaging, as Jose pointed out, are part of a big package of their own which merits this. They also get more extensions regularly. - OG has it's own category of 58 items http://drupal.org/project/Modules/category/90 - Panels provides many menu items itself which probably justifies this top level status without any sub-items. Perhaps it could be moved to some sub level like "Administer > Display" that could hold other "Display" related items. As Daniel proposed, we could push these top level items into an existing top level items and let the menus nest a level deeper. I don't think that will work. If you think our hierarchical menu system is good think about how you and other power users navigate Drupal's admin area: by mouse or by URL bar. We use the URL bar much more often which, IMO, points to a general "Menu system fail" (see https://video.devseed.s3.amazonaws.com/spaces_features_final.mp4 for recent evidence of URL bar navigation). Admin_menu "solves" this problem, but as much as I love admin_menu there is plenty of research that dynamic dropdown menus are too difficult for most users which means that simply pushing the menu hierarchy deeper is not a solution. ** Proposed guideline: If your module is part of a commonly configured package of modules consider creating a new top level menu under admin/ and consolidating related items under that menu. If your module will likely have fewer than 5 items at that level consider reconfiguring the screens to reduce menu items or merging it into an existing menu. Regards, Greg -- Greg Knaddison http://knaddison.com | 303-800-5623 | http://growingventuresolutions.com
On Sun, Feb 1, 2009 at 6:17 PM, Daniel F. Kudwien <news@unleashedmind.com> wrote:
This goes out to some maintainers, specifically related to
- Notifications / Messaging - Organic Groups - Panels
Those and related/dependent modules are implementing top-level menu items, e.g.
- admin/messaging - admin/og - admin/panels
in the style of Drupal 4.7, instead of using the new administrative categories and structure we have since Drupal 5.x. This is not only confusing, but also clutters the administrative interface - especially, if Administration menu module is installed.
Although my fine module was not mentioned here, l10n_server does this same thing, so I am kind of feel like called out :) Others from Panels and Notifications/Messaging provided their opinion, so I'd not chip in, if I'd say the same. But maybe I am saying the same. For the l10n_server case, the separate high level item makes sense, since the l10n_server is a kind of standalone software. It does not help you track users, enter content, vote on content or whatever, but in a sense it does all of these. it has a highly specialized storage and UI system for translation editing and reuses Drupal capabilities to set up users, languages, organic groups, panels, blocks, whatever around itself. The module in itself is not related to site building, configuration, users or reports. It is merely a "high level tool" on your site you'd use. Now that I said it, I might have said the same things as others said on Panels and Notifications/Messaging, maybe in a more general way. And yes, I am an admin_menu user. I was the guy, who pushed it to be used on d6.drupal.org last week :) And yes, I appreciate high level tools highlighted on the highest level in my admin_menu. And yes, I understand that Panels, or Notifications/Messaging or l10n_server might not have the highest importance to people *once* they set up everything, and would instead only focus on core site management such as user, content and logs. Gábor
On Mon, Feb 2, 2009 at 12:50 PM, Gábor Hojtsy <gabor@hojtsy.hu> wrote:
On Sun, Feb 1, 2009 at 6:17 PM, Daniel F. Kudwien <news@unleashedmind.com> wrote:
This goes out to some maintainers, specifically related to
- Notifications / Messaging - Organic Groups - Panels
Those and related/dependent modules are implementing top-level menu items, e.g.
- admin/messaging - admin/og - admin/panels
Here is an idea. Perhaps what we need is admin/applications/ above all the modules that do not readily fit under the rest of the existing hierarchy (Content, Build, Settings, ...). - admin/applications/messaging - admin/applications/og - admin/applications/panels i18n would not fit under there, but it could have a "Languages" heading with others going under it. - admin/languages/i18n - admin/languages/locale - admin/languages/translation This would solve the issue for admin_menu, and also the clutter. -- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting. Simplicity is prerequisite for reliability. -- Edsger W.Dijkstra Simplicity is the ultimate sophistication. -- Leonardo da Vinci
Seems to me that we should move locale.module and translation.module to a new top-level menu item, then contrib modules like i10n_server could add themselves there - opened a core issue for this here: http://drupal.org/node/368064 (and similar for simpletest/devel - http://drupal.org/node/368067) Nat
For the l10n_server case, the separate high level item makes sense, since the l10n_server is a kind of standalone software. It does not help you track users, enter content, vote on content or whatever, but in a sense it does all of these.
Gábor
these are just menu links. if you don't like where they are, move them. there are good arguments on both sides. hardly merits a long discussion, IMO. On Mon, Feb 2, 2009 at 12:50 PM, Gábor Hojtsy <gabor@hojtsy.hu> wrote:
On Sun, Feb 1, 2009 at 6:17 PM, Daniel F. Kudwien <news@unleashedmind.com> wrote:
This goes out to some maintainers, specifically related to
- Notifications / Messaging - Organic Groups - Panels
Those and related/dependent modules are implementing top-level menu items, e.g.
- admin/messaging - admin/og - admin/panels
in the style of Drupal 4.7, instead of using the new administrative categories and structure we have since Drupal 5.x. This is not only confusing, but also clutters the administrative interface - especially, if Administration menu module is installed.
Although my fine module was not mentioned here, l10n_server does this same thing, so I am kind of feel like called out :) Others from Panels and Notifications/Messaging provided their opinion, so I'd not chip in, if I'd say the same. But maybe I am saying the same.
For the l10n_server case, the separate high level item makes sense, since the l10n_server is a kind of standalone software. It does not help you track users, enter content, vote on content or whatever, but in a sense it does all of these. it has a highly specialized storage and UI system for translation editing and reuses Drupal capabilities to set up users, languages, organic groups, panels, blocks, whatever around itself. The module in itself is not related to site building, configuration, users or reports. It is merely a "high level tool" on your site you'd use.
Now that I said it, I might have said the same things as others said on Panels and Notifications/Messaging, maybe in a more general way.
And yes, I am an admin_menu user. I was the guy, who pushed it to be used on d6.drupal.org last week :) And yes, I appreciate high level tools highlighted on the highest level in my admin_menu. And yes, I understand that Panels, or Notifications/Messaging or l10n_server might not have the highest importance to people *once* they set up everything, and would instead only focus on core site management such as user, content and logs.
Gábor
participants (13)
-
Daniel F. Kudwien -
dragonwize -
Earl Miles -
Earnie Boyd -
Greg Knaddison -
Gábor Hojtsy -
Jose A. Reyero -
Khalid Baheyeldin -
Margie Roswell -
Moshe Weitzman -
Nancy Wichmann -
Nathaniel Catchpole -
Walt Daniels