Requirements for Administration menu in Drupal core

Mission critical:
#276751: Allow to alter/customize/add links in administration menu

Mission critical (Drupal core):
- Allow retrieval of an entire, expanded menu tree, including all local tasks.
- Allow to output certain items in a menu tree for a certain "owner" only (displayed in admin_menu, but not in regular menu blocks) - or - Allow to merge two menu trees.
- Allow menu items to link to local files (update.php).

Extensibility:
#420828: Allow dynamic replacements in the menu
#420816: On-demand loading of dynamic paths and local tasks #1
#293768: Allow to enable/disable menu additions

Performance:
#349505: Performance: Cache menu tree
#345984: Client-side caching of administration menu
#420840: Ensure Drupal.behaviors.adminMenu is only executed once
#420806: Ensure proper rebuilding of hash and menu
#420802: Prevent separate AJAX request for clients without client-side cache
#420812: Implement hook_js()

Usability:
#315342: Add "My account"
#220100: Add support to detect hover intent (no dependencies added)
#331982: Add support for keyboard navigation
#226012: Merge Administration Menu Dropdown module (optional, unsure)

Clean-up:
#420836: Move module functions into include file
#420808: Remove obsolete caching
#266099: Allow to configure margin-top setting per theme
- Move Drupal administration tweaks unrelated to the menu itself into new admin_tweaks module.

Current focus: #345984: Client-side caching of administration menu - tests, reviews, and architectural feedback greatly appreciated.

I updated and ordered the list by priority; current focus is on all extensibility and performance issues.

Cross-posting a private mail:

I am not entirely sure what MBD is proposing in http://www.d7ux.org/header/, because the envisioned behavior is hard to understand from a single screenshot/mockup. If I'm not mistaken, the first row in that mockup is more or less admin_menu with a different theme. Adding support for different themes is on the list of long demanded features and shouldn't be that hard to achieve. We already started to open the door for Color module integration a few days ago, which is a bit different, but in the right direction.

The second row looks like it would expose dynamic links depending on the context of the current page. That is something I was already discussing with Earl Miles in the past weeks, because he desperately needs a way to expose and place/locate administrative, contextual links for Views and Panels on pages. The resulting functionality could surely be enhanced and adapted to work with other contexts, too.

However, it is also possible that MBD is proposing something completely different: A *two-level* "icon menu", more or less completely depending on the current page's context, which does not expand the menu items in the top row. That is different, because admin_menu's primary design goal is to expose and provide immediate access to all administrative pages in the system (including deeply hidden ones), since it is the invisibility and ignorance of not knowing what is "under the hood" that makes people feel lost. We are already working on exposing further, dynamic pages in the system, such as direct access to individual menus.

In addition, I continued to consider how admin_menu could be able to make further modules obsolete (see discussion). For example, the Navigate and Teleport modules, which provide

a) a search bar,
b) a trail of last visited pages, and
c) per-user bookmarks for often visited pages.

All of these are very reasonable UX concepts and they would be pretty simple to implement (as optional features), but I'm rather investigating what their common denominator is and how admin_menu could be turned into a pluggable admin interface. Because:

If anything lands in core, it has to be open, extensible, and customizable.

And, yes, Peter is right that admin_menu's port to D6 introduced a rather bad architecture. My plan is to investigate how the menu system needs to be improved to allow admin_menu to use it directly. Roughly, it might boil down to:

• Allow retrieval of an entire, expanded menu tree, including all local tasks.
• Allow to output certain items in a menu tree for a certain "owner" only (displayed in admin_menu, but not in menu blocks)
  - or -
  Allow to merge two menu trees.
• Allow menu items to link to files (update.php).

Additionally, the fundamental idea and design of the recently introduced (and rocking) client-side caching of admin_menu in 3.x could be moved as generic implementation into core already, because the concept is pretty trivial and could be really useful for JavaScript-based features in other modules.

In general, I am highly opposed of rushing admin_menu or something like admin_menu into Drupal core. IMHO, UX-stuff like that should only be moved as-is, which means that the entire concept and design *was* tested and approved by aforementioned 40,000+ Drupal users already. Any changes to how it looks, feels and works will make it worse -- not only from a technical view (think browser compatibility), but also regarding user experience: I have to deal with such "WTF happened to xyz?"-issues in admin_menu's queue mostly after every single change.

That means: I'm specifically opposed and highly worried about this proposal:

2a. Implement a "header module" from scratch, or alternatively,
2b. Rework the admin menu module so it becomes a header module.

However, I am confident that we can get the module into this as-is state. Maybe for D7, maybe not, that's unimportant. Important is to move something that has been tested thoroughly and is known to work.

On a related note, this is also the part that I do not understand in the current UX work that is going on. Some of the proposed UX improvements are already implemented in contrib modules (proof-of-concept or not), but it seems like the team rather wants to re-invent the wheel, putting something in core that - opposed to those contrib modules - had no real world testing under different use-cases before. (see also above about designing contextual, administrative links for Views/Panels)

On that entire "move this stuff into core" note though, we should also consider whether moving more applications into core is the proper approach for the future. As someone mentioned on the development list, the "Drupal" distro could as well package admin_menu into its modules directory.

Thoughts?

uh oh - what is this?! Something must have hi-jacked my HEAD?