Administration menu or admin_menu should be in core

I have learned that Administration menu is for advanced Drupal users only.

I am quite sure that marking this issue won't fix makes a few other Drupal contributors happy.

It does not make me happy. Especially, because it is my belief that every CMS needs to expose its functionality the way admin_menu does.

However, we have a UX team (and even had a few "UX experts") that already "took the decision" that admin_menu does not belong in Drupal core. Whatever that decision is based on.

Drupal core contributors, as of now, spent a lot of time for duplicating a tiny part of admin_menu's functionality. That work has been committed. And within the remaining time-frame, there is no way to revert and replace this with a proper implementation.

Since most of the current UX efforts seem to forget about the actual user, I'm still trying to prevent other shit from hitting the fan (core) as much as possible. But it's especially hard to follow all issues, because the actual conception lives deeply hidden in arbitrary videos on the net (which is quite similar to the new, envisioned IA for Drupal).

From now on, your first step after installing Drupal is to disable Toolbar module and enable Administration menu.

Period.

admin_menu was never in core, so there is no issue with:
"Not keeping it in core merits better explanation than what has been given here or elsewhere, imho.".

I think what sun is trying to explain here in a diplomatic fashion (correct me if I'm wrong sun) is that he advocated and tried to get admin_menu in core and was passed over in favor of the current incarnation in D7.

+1 or a -1 from me is moot as the decision has already been made in this area from what I understand and based on what I see when testing D7.

there is no way to revert and replace this with a proper implementation.

The above is pretty important information, and beyond that eyes and ears are on other issues with the pending code freeze. That said, next time up would be D8.

I think what sun is trying to explain here in a diplomatic fashion (correct me if I'm wrong sun) is that he advocated and tried to get admin_menu in core and was passed over in favor of the current incarnation in D7.

I think that this was the diplomatic fashion of my frustrated rant.

Anyway. To also close down #543932: Remove the words "It's a helper for novice Drupal users" ?, let me clarify: It was the UX team's decision that Administration menu is suitable for advanced users only. I won't (ever) agree with that, but it is their (wrong) assumption.

D7 has to live with the half-baked thing called Toolbar. Until this gets relevant for D8, Administration menu will have advanced to further areas (probably always >2 years ahead of Drupal core). So there is no point in keeping this issue active.

D7 has to live with the half-baked thing called Toolbar. Until this gets relevant for D8, Administration menu will have advanced to further areas (probably always >2 years ahead of Drupal core). So there is no point in keeping this issue active.

This is just sad.

admin_menu is awesome and always the first module I install. I can't believe it won't be in D7 core. Browsing the admin-pages without it is simply frustrating. As I see it, leaving it out can only benefit Drupal's CMS competitors.

Sorry for the bother, but can someone tell me what is it that makes admin_menu for advanced users only? Maybe some UX Expert wants to clarify?

Wow, this is sad indeed. I have tons and tons of drupal install batch and script files to ease installation and testing of various 'distributions' and admin_menu is the only contrib that appears in absolutely ALL of them. It is, without a doubt, the single biggest time saver in existence. And yes, I found it, installed it, and used it, when I was just a novice.

What's worse, is I checked out checked head this past weekend for the first time in a month or two, and was completely thrown by the new "IA" and toolbar module. Nothing worked as expected. Granted I'm not a novice any more, but I still shouldn't have been so completely thrown off.

I was a usability engineer for many years-- one of the reasons I sought to leave was exactly because of the rise of the so called "experts" at the expense of actual users. Anyone can posit a hypothesis and obtain user test results to reinforce their agenda-- it's really not that difficult. Though in this case it sounds as if the phony user tests were completely bypassed. It's really too bad.

The only good news is with drush I can even automate the disabling of the toolbar and enabling of admin_menu. ;-)

It seems like people want to discuss this publicly.

I think discussions like this help people to see things that perhaps they had not considered, and thereby aid the development process.

I normally would expect to at least be able to understand the reason for the decision, even if I may disagree with it. I just don't see this at all. Please help me to see it. If anyone can point out the benefit - real or even imagined - to newbie users of not having this in core, please share this here. (I'm not talking about the reason that says "it's not for novices" - I'm asking, what is the reason that it is it not for novices? WHY is it not for novices?)

I usually can see arguments for AND against a lot of things - say, Drupal and Joomla. Though I prefer one, and perhaps even think the arguments against the other are not valid, I can at least understand what the arguments are - what they say and claim (even if I tihink the claims are false).

In this case, though, I honestly fail to see any reason at all for this decision. Excuse me if I am missing something. If there is any rationale, it would clarify the issue and help this discussion to have any reason(s) declared. (I am almost thinking there aren't any.)

If the reason is that it's too complicated, then I would ask, isn't the Naviagation menu already there with the same items? Isn't that just as complicated? Even more complicated, since it's a bit more difficult to access, and thus "more hidden" and more difficult?

Anything that makes the job easier makes sense for the novice. The novice would benefit from this.

In a big project, with lots of decisions to make, and a rush to make them quickly, it is possible for developers to overlook the reasons for making one decision, and not give enough time to consider it thoroughly, so that a wrong decision could be made. I hope this isn't happening here but it looks as though it may be.

Just to add to the support, I didn't know this issue already existed when I posted #557352: Admin Menu preserves my Drupal 7 sanity in the Admin Menu issue queue. I didn't quite get why we'd have a toolbar in core without dropdown menus when Admin Menu has been doing this elegantly for some time. With the extra toolbar styling module enabled on the site, Admin Menu rocks my socks. \m/

Basically, I collapsed the Toolbar first, because it took up too much screen real estate. I then later discovered it was a module and that Admin Menu had a 7.x-dev release, so I disabled Toolbar and enabled Admin Menu straight away. This may be because I'm advanced, but when it came to the D7 IA I was a total novice and was absolutely lost. (There was already a related issue, but I totally didn't grok the "People" menu....) Having hierarchical dropdown menus was incredibly helpful, especially since they included the tabbed pages that weren't immediately obvious to me on some of the admin pages.

I think the toolbar will meet a lot of people's needs. Let's keep it this way for Drupal 7 and re-evaluate for Drupal 8. I've never been a big fan of Administration Menu. It also send the complete administration menu on each request. Not my kind of thing performance wise.

Let me just quickly spit in that Davy's point about performance is not true. Administration menu always cared for maximum performance, and 3.x even goes beyond might and magic by being displayed on all pages without actually processing nor outputting anything at all to display it. You will say that this is impossible, but then again, you will have to learn it is indeed possible.

-1 for admin_menu. Don't like how it drops down its gigantic menu as soon as you mouse over it. It should at least have hover intent to keep it from being over sensitive.

See #220100: Add support to detect hover intent (no dependencies added).

I just have to chime in to all the naysayers here that the usage statistics say different-- admin_menu is 6th on the list of most installed projects. Sixth! Moreover, all the projects above it have been included in core or are discussing/working toward core inclusion. It's also consistently in the 'top rated' and 'top downloaded' categories at drupalmodules.com. Sorry, but if we're going by the 80/20 rule here a handful of naysayers would be clearly in the '20' category. I'm quite confident that in this case the '80' will be disabling the core toolbar module and installing admin_menu but time, and usage statistics, will tell.

Yes I know these numbers are not absolute, but they can sure be used as a rough gauge. I have no clue of the details of the "not for novices" pronouncement (including the when, where, how, and who said it) so this is completely nonpartisan gut reaction on my part, but had it not been for some 'expert' pronouncement or the d7ux project, one has to wonder if this would even need to be a discussion.

And on a completely different tack, with all the important work to be done on core drupal, it seems really quite the waste of time to reinvent the wheel when an enormously successful tried and true contrib project, which has already worked out many of the same issues, is just waiting in the wings. It really leaves me head scratching.

Of course I don't yet contribute to core to this is all a big 'imo'-- take it or leave it.

I used Administration menu, and I removed it only recently because a problem that is not caused by the module.
I found it very useful; the fact the menu shows every time I hover the mouse has not stopped me from using the module.

I was wondering (not having looked at the code of Toolbar, and not knowing how its code differs from Administration menu) if it would be possible to integrate Administration menu with Toolbar. What I mean is that Administration menu could alter the output of Toolbar; in this way, the user would enable Toolbar, and Administration menu if he needs more functionalities.

I don't know if this is possible, or it makes sense; it's just a thought I had.

I didn't realize this issue had been re-activated until WorldFallz pointed over here. I want to add my support for admin menu. I realize that getting it into D7 core at this point is pretty well impossible but add me to the list of folks who will be adding it from contrib to every site I make.

You have a wonderful module, Sun. Don't let the usability folks tell you any different.

Michelle

+1 for what Michelle said. Enabling admin_menu (and now, disabling toolbar) will still be step number one in development for me.

That said, I'm not at all concerned that it didn't make it into core as I know it will progress a lot faster (read: at all) here as opposed to sitting stagnant in core. Admin menu has always been one of those modules that I'm excited to see what the next version brings, and as you said, it's always a little ahead of its time. Being introduced to core would ruin that, IMHO.

EDIT: Is there an issue somewhere where the discussion and decision to not add it to core took place? I'd like to read over the arguments.

i've been reading the conversation here and wanted to add some perspective from the D7UX project point of view.
Mark & I acknowledge and agree that the admin_menu module has made a significant improvement to the Drupal UI for many people and that is why it is such a popular and routinely installed module. We fully expect that it will continue to be incredibly popular, particularly with Drupal developers.

At the same time, flyout menus represent both usability and accessibility issues for many users, particularly the users we are seeking to better represent as a part of the D7UX project (ref: http://www.d7ux.org/who-is-d7ux-for/).

From a usability perspective, there is a significant proportion of the end user population who routinely use only an incredibly small subsection of Drupal's toolset, the admin_menu makes it quite difficult for them to pick out these very few but very important tasks by doing exactly what you more experienced and proficient end users value - providing everything within a single click.

From an accessibility perspective, the flyout menus require a significant amount of physical dexterity in order for end users to perform tasks without error. Again, those of us fortunate enough to be able to wrangle a mouse with accuracy may find the flyouts extremely efficient, but for the very many people who can't (and for us if we happen to sprain our wrist or something similar) it is not a great strategy to make the primary navigation interface something that requires such dexterity.

please don't think that the fact that we have not recommended including admin_menu as a part of D7UX implies that we don't think that it is a great asset to Drupal and, for the intended target audience, well beyond fit for purpose. But within the scope of our project and for the target audience that we are seeking to represent, it is not the ideal approach.

I hope this is helpful

@Leisa - makes perfect sense. : )

Maybe this is too much trouble, but what about Admin Menu w/ various menu profiles that can be assigned to users by role? Drupal allows you to setup input formats and make those available to different roles. The WYSIWYG modules (at least FCKEditor) allow you to setup WYSIWYG profiles that you assign to different roles. What if we had Admin Menu with all its potential available and had usage profiles... for regular ol' users, it could function the same as the Toolbar currently does. For advanced users, it could function the same as Admin Menu currently does.

And I realize this is not exactly a straightforward operation given the way Admin Menu must work with the menu system. Maybe it's not even worth it, but it does seem like it could lead toward a path of 2 dead birds and 1 stone on the ground beside them.

Flyout/dropdown menus represent usability/accessibility issues? Accessibility is taken care of. And the vast majority of the target audience knows exactly this navigation pattern from many, many other CMS, desktop software, web applications, internet portals, etc. If that pattern is not usable, then I must wonder, which other pattern the target audience is more familiar with. Furthermore, the (new) "Toolbar" style for it uses the same large font and spacing as the Toolbar in D7 does. If that leads to accessibility issues, then the Toolbar in D7 has accessibility issues.

I can only recommend reading #16 again. It is not about providing expert tools for advanced users. It is about allowing the user to understand what is under the hood. That is the first and foremost usability issue Drupal has to solve with regard to its navigation.

Drupal is not a naive blogging tool. It's a flexible, modular site building tool. For that sake, the day-to-day tasks are not limited to creating and finding content, but instead, constantly building, extending, and rebuilding a site. Users want to achieve something. They do not want to see the fancy and omg-so-usable buttons on all the time-wasting pages they need to click through.

Obviously nothing will come of our discussion here at this point, a few days before code freeze and after hundreds of man hours spent on the D7UX toolbar, and I think we're being a little hard on Leisa, but I can't help but play devil's advocate.

I'd like to point out that the flyout menu functionality in admin_menu is practically the same as the menu system in almost every desktop application (even the browser the user uses to reach their Drupal site to begin with) except admin_menu activates on hover and desktop app menus activate on click (which, if anything, is less accessible IMO). So yes, it may be difficult for users with impaired motor skills or concentration shutters, but not any more difficult than every desktop app.

Also, IMHO it's a valid concern that so many options/menu items might be difficult for the know-nothing client that just wants to add a blog post, but that's a problem that can (and would) be easily solved by implementing something like what was mentioned in #28. Nobody expects to throw a module into core without changing it in some way. Even though that just happened with CCK HEAD, cases like that are definitely the exception.

BUT once again, I'd still prefer it stay in contrib so sun can maintain complete control over it. I just think the reasoning is off.

All these opinion powered arguments aside-- sorry, I have to say it again, but the usage statistics, however rough they may be, speak for themselves. If the guiding principal really is 80/20 (which I've seen mentioned over and over and over again in all sorts of posts and issues) and it's not just lip service to justify a particular agenda, we are clearly going against that philosophy here. At the very least, such a decision warrants more than "imo" which is all I've seen to this point.

Also, no one said admin_menu was perfect in it's current state-- I'm sure there are improvements that can be made (like a "favorites" or "quick launch" menu, hoverintent, mega drop-downs, etc.)-- there always are. I just can't help but think how much further along this effort could have been if it started from admin_menu.

I've seen quite a few of the d7ux decisions that could be argued either way but never said anything because I didn't have the cycles to participate and instead chose to defer to the all the hard work that team has done. However, this one just plain eludes me.

Then ?

I think we're arguing the same point. We're both saying that there's not much truth to the argument that flyout menus automatically make a menu inaccessible.

just scrap the admin bar and get Admin_menu into core, please!

Freeze is in 5 days. This simply isn't going to happen. But I've been told that the toolbar in core is disable-able. So those of us who want to continue using admin menu can do so.

Michelle

The toolbar is disable-able indeed. It's just a module providing a "Custom menu". You can add links to it. Kind of like "quick links, favorite links". So admin menu can still grow. We have 2 alternatives now. The toolbar and admin menu. I noticed a lot of colleage Drupal developers install it on their client's sites. The clients like it. They've never haten it. But now we can see what an alternative (well, almost alternative) can do. I stay with my earlier point... Let's see how adminstration menu evolves and start working to get it in 8 asap. And lets see what people think of the toolbar.

@kaakuu: Getting something into core is not trivial. It's not just a simple "mv admin_menu/". Even the smallest patches get tons of scrutiny, fixes, rerolls. Tests need to be made, bikesheds painted. There is simply no way it would happen in 5 days.

Michelle

Guys... You've made your point about the usage base. We all accept that. I was talking about how it will compare next to the simpler toolbar. Will as much people need admin menu? Will toolbar grow to admin menu? A symbiosis?

Getting something into core is not trivial

Correct, and that's not counting the time it would take to convince the entire Drupal community that has already committed itself to Toolbar (if that's even possible after all the time spent on Toolbar).

@kaakuu, sorry, by "entire Drupal community that has already committed itself to Toolbar" I meant "The group of Drupal users who ARE committed to Toolbar" not the entire Drupal community as a whole. Should have clarified.

But we are speaking of something which is ready to get into the core

That's not necessarily true. 1.x doesn't fully invest in Drupal's menu system and 3.x isn't ready until a bug in the menu system is fixed (see #550254: Menu links are sometimes not properly re-parented). If a version of admin_menu were to be committed, it would have to be 3.x as it does things more like "the Drupal way" but nobody's going to feel ok committing a module to core that hasn't even made it to full release yet. It would have to be fully tested, abused, code-reviewed, revised, and tests would have to be written against it. As Michelle said, it's just not going to happen.

Speaking as a Drupal developer and administrator deeply involved in accessibility issues, and being a blind screen-reader user myself...

1. It is a fundamental misconception of accessibility to think that a site needs an "accessible" theme, any theme designed properly should be accessible to users with disabilities.

2. The toolbar does currently have accessibility problems which need to be resolved, as does tabledrag, there are currently issues filed against both of these in the issue queue, we'd love your help. I have not tested the administration menu, but I imagine it does have accessibility issues as well. I doubt either component has accessibility issues that can't be corrected with community willingness.

3. I am less concerned with those who have sprained wrists, as aweful as that must be, and more concerned about making all parts of Drupal accessible to those of us who live on a persistent daily basis with accessibility challenges.

We should then talk about scaled down versions of Views, CCK etc too

Actually, Drupal 7 contains in core just a part of CCK.

@kaakuu I appreciate your zeal for the issue, and I've already posted in this thread twice in favor of the issue... but really, the nature of your responses here comes across as combative with the very people who agree with you and also have a firm understanding of the feasibility of the task for D7. Continuing to repeat the same facts will alienate the people you should be appealing to to support Admin Menu in contrib and target D8. I'll stop weighing in if you continue to pester people about a D7 inclusion.

That said, there's good precedent in the Token module for essential modules being bypassed in one release and included in the next. I'm very happy it made it into D7. I'm sure it didn't hurt for it to be able to mature another year in contrib.

Actually, Drupal 7 contains in core just a part of CCK.

Nope, now that #516138: Move CCK HEAD in core is committed, it's got the whole thing :)

@kaakuu: Even 3 weeks wouldn't have been enough time to convince people to undo toolbar, which we've spent months working on, and still have time to get a new module in core. Even 3 months would be pushing it.

@Everett Zufelt: I was wondering how you kept pulling out those much needed accessibility reviews on core patches recently :-) ...really glad to have your help here.

The Admin theme being developed for D7 is off the chain, very nice, now in it's own module "Admin" module. It's much better than the Admin Menu, which is why I no longer use the Admin menu. The only thing I'd like to see in the Admin theme is menus like "run cron, current module project pages, clear cache,etc" Admin menu has this.

i say no to adding Admin menu in core and yes to Admin module which I think is already planned for D7 core.

@espirates I think the main thing that people miss from admin_menu that Toolbar doesn't have is the ability to jump to ANY page in the backend with a single click (along with the clear cache, run cron, etc. that you mentioned). As long as Toolbar doesn't have that ability, I'll be sticking with admin_menu.

@leisareichelt - Thanks for explaining the rationale!

And, definitely, this much is true. "...there is a significant proportion of the end user population who routinely use only an incredibly small subsection of Drupal's toolset,..."

However, in my opinion, the admin menu makes things easier for these folks!

Here's why I think so:

- Without the admin menu, novices who click a menu may still not see what they want, and have to resort to "poking around" with various menus until the items they want show up.

- With the admin menu, because items are not as "hidden", there is less "poking around" and it is therefore easier for the novice to find what they are looking for.

So, seems to me the admin menu still makes things easier for novices.

Thanks for considering this.

Point well taken, however, it's been my experience as a novice user and also as a more experienced one that making users (especially beginners) go through all the menus helps them to understand Drupal a whole lot better. There are menus in there that may go unnoticed if they click too quickly. I think a nice option for Admin Theme would be to customize the submenu so we can add what we want there.

The Admin Theme gives a wonderful setup/view to move through various sections with ease. I like the fact that on my way to a particular menu, I can see the whole set and often I change my mind and want to go to another area, this is easy in the Admin Theme. The only things I miss about Admin_Menu are the run cron, clear cache and link to project issues which is very convenient and Admin_Theme plays nicer with the custom theme too.

Each module has positives, but I think combing Admin_Menu best features into Admin_Theme would be win win for everyone.

I think combing Admin_Menu best features into Admin_Theme would be win win for everyone

IMO, that best feature *is* the fact that you can get anywhere with a single click, which they obviously can't achieve in Toolbar without using Flyouts of some sort, and the Usability folks have already said that's not going to happen.

I agree with Leisa on this one. The Admin Menu module may be helpful when you have a small number of modules installed, but for me it's been virtually unusable on complex installations where you have 60+ modules installed. The Admin toolbar/theme is simpler since it only includes links for the most common tasks, and each task is associated with an icon. And if there are tasks that you want to add to it, you can, since it's just a regular Drupal menu. (At least in the D6 version; I haven't tried it in D7 yet.) I only wish that it had links to clear cache, rebuild themes, etc.

Anyway, there's no chance that including Admin Menu will happen for D7. I think it's great that Admin Menu is out there for the users who benefit from it, and free to follow its own development in contrib. Should we set this one back to "won't fix"?

After reviewing the D7 version of the Admin Toolbar in its current state, I have to retract my previous comment about its usability. It bears very little relationship to the Admin module for D6, which is quite useful.

The Admin module for D6 was configurable through the Menu module interface, and it had a wide range of tasks on it by default. You could click on the main heading and the shortcuts would appear underneath, each associated with an icon.

By contrast, the "shortcuts" for Admin Toolbar for D7 can be configured through the Menu module interface, but there are only three of them by default, and there's not a list of the other administrative tasks which one can then choose to enable. Even more frustratingly, the JS from Admin module for D6 which changed the shortcuts depending on what top-level option you clicked is missing. This render the shortcuts useless in my mind, and prevents this module from actually being useful to navigate the Drupal admin information architecture.

I just wish that the version of the Admin module that's going into Drupal 7 had been close to what was created as a Drupal 6 module. That version has been widely used "in the wild", and I've personally seen how it helps non-techies use Drupal. Are there any changes that can still be made to the D7 Admin module post-code-freeze to make it hew closer to the way the D6 Admin module works?

BUT once again, I'd still prefer it stay in contrib so sun can maintain complete control over it. I just think the reasoning is off.

Totally.
Core is dead.
Keep this thing in contrib, and I'm sure we will see a lot of nice improvements over time, more than we would see if it was in core.

I think the real issue is that we don't want to spend time enabling enabling a bunch of default modules for each new Drupal install.

The solution is: install profiles, "distributions", or other ways to quickly download and enable a lot of modules. For myself I use a "module enabler" module. The only thing it does is have a huge list of "dependencies[]" declarations in the info file, which I generate from counting enabled modules in the system tables in other Drupal installs I have. I guess others have their own methods.

For new users, I think we should have "featured distributions" on the download page.

----

About usability.
I think for anyone who wants to install and administer a Drupal site, the admin menu is far superior to any other tool imaginable. Most importantly, it provides an overview of all that is possible with the currently installed modules.
However, we need better tools for the usual "content editor" - that is, the client who wants to write blog articles etc. If the D7 toolbar does that, I dunno - I only had a short glimpse.