There is a discussion at http://groups.drupal.org/node/19171 regarding revamping the administrative menu. It seems to me that the issue of the improving the menu INTERFACE is different than the issue of STRUCTURE. Here, I'd like to see if we can gather the discussion of practical alternative menu interfaces for core. As I mentioned in the aforementioned thread, please let me know if I'm duplicating efforts here.
Drupal has two menu interfaces by default: 1) the navigation block and 2) top-level admin pages (i.e. admin/build). Many users don't consider this sufficient for usability, for example Acquia Drupal ships with Admin menu to make navigating the menu quicker and easier. Ultimately, it seems that there needs to be an additional, more usable menu interface that ships with core which improves the speed of navigation and administration.
I think there are three questions that need to be answered before any real progress can be made on this front:
1. Does Drupal need an alternative menu interface in core, or is this a problem that should just be solved with contributed modules?
I think the general consensus is that we need something better in core that what's there now, but I want to make sure I'm reading the community right on that.
2. Should Drupal provide a ubiquitous space for administrative / navigation tools which won't interfere with the layout, much like the space claimed by the Admin Menu or Navigate modules?
This seems like an important decision to make. Right now administrative / navigation tools either have to work in the content - a block, for example - or do some trickery to set it outside of the theme. If Drupal offered a supported space (or spaces) for ubiquitous admin tools, then it would be much easier for core and contrib to be consistent with these tools.
3. What features are essential for a highly usable menu interface, and which are priority?
This would be a base set of features that should be included in the core menu interface. Please give feedback on any of these items (I will try to consolidate this list as discussion proceeds):
- Menu search - Ideally auto-complete style
- User-based menu bookmarks - Allow users to have their own set of bookmarks or favorites
- Collapsing menus with saved state - When using collapsible menus, state should be saved from one page to another
Comments
...
However, I think this discussion needs a bit more clarification. It seems you want to focus on alternative "observer patterns", i.e. utility approaches that (might) ease the management of a Drupal site for Drupal users that already know Drupal. This is a category admin_menu does not belong into, because it statically exposes an already existing menu tree only, using an user interface concept, which everyone who touches a computer already knows.
But yes, some folks started to derail the other discussion with this offtopic talk about such utilities. So, thanks for moving it here.
Daniel F. Kudwien
unleashed mind
Daniel F. Kudwien
netzstrategen
Thanks for your thoughts,
Thanks for your thoughts, sun, glad I was able to do my part in keeping on-topic.
It's not that I'm advocating tools that are only useful to users more familiar with Drupal, rather tools that are useful to the new user right immediately, and that scale well to be useful to even long term users.
Re #2: Each interface you mentioned does indeed forge its own space. Many administrative tools, however, would fit nicely into a collapsible left side bar outside of the theme. There are exceptions, but if we could establish a default space for such tools, it may foster innovation to tackle navigation / administrative issues. The core administration displays as a block and directly affects the content of the page. I'd go out on a limb and say that this kind of stuff belongs outside of the theme. Admin menu is outside of the theme, and for good reason.
I'm not sure the answer is yes, this should happen, but I can see some good arguments for it.
Re #3: I agree that teleport is definitely for more advanced users, but only because it requires a keystroke to activate. The search feature, in contrast, seems like it can be intuited right away. The search allows one to search for things they'd like to do or find by keyword. I'd contend that this is useful for all levels of users. Want to create some content, or add a new user? Want help? Start typing a keyword, it works just like other kind of search. There will also be new users who are trying to remember the page they were just on. They might not know where it is but know what it's about, which I think makes a great case for menu search. I'd love to see how some usability testing goes with a menu search prototype. Could prove me wrong, but I suspect otherwise.
You mentioned that admin menu only exposes an existing tree. I'd say that search also exposes the same tree, just non-hierarchically.
The idea of Favorites / Bookmarks is also a familiar concept, though definitely less common in web apps. There's no need to know anything about Drupal to use it, and it seems a useful convention that would helps new users keep breadcrumbs, and seasoned users quickly access items their own way, without having to worry about affecting a menu for all users.
I realize you've probably got your work cut out for you on other stuff, but if you have a minute, I'd love to hear some clarification on the points above. No doubt my thinking could use some honing in this area, which is why I'd like to understand your points of contention more clearly. Thanks!
Chris Shattuck
Learn Drupal with over 1700 Drupal video tutorials
When admin_menu's story
Daniel F. Kudwien
unleashed mind
Daniel F. Kudwien
netzstrategen
Interesting to hear a bit on
Interesting to hear a bit on admin_menu's history. Thanks again for your feedback.
One of your points basically articulates what best case scenario would be for this thread, i.e. "all maintainers and developers of those modules should join forces to create a new, consolidated, extensible, customizable, and innovative admin dashboard/finder module". Before that can happen, I would think there would need to be a gathering of minds and ideas and see if we can give that a shot.
Your point about search is well taken. Search is not a complete solution and I don't suggest it as an exclusive alternative to the hierarchical tree, but rather a parallel, complementary interface. The basic hierarchical structure of the site is important, and should not be inaccessible (especially for discovery, as you mentioned) but forcing a user to grok the tree structure seems like it shouldn't be a requirement to using a Drupal site effectively.
A search / favorites paradigm is used in many applications successfully to reduce a complex structure into the parts you use most, and as Drupal sites grow with complexity, this sort of feature increases in usefulness. I personally end up browsing this way almost exclusively on my sites because of speed, and I encourage clients to do the same (using the Navigate module, for now). Use case: When you install a new module, you know there must be an admin page, but aren't certain as to where it might be. You search, find it, maybe bookmark it if it's going to be a page you'll access regularly, and you're done. You've found it quickly and made access to it even quicker. Like I said, this might just be my style, and it would be up to usability testing to see if it would be a paradigm used by others.
It sounds like you're not terribly impressed with the quality (and quantity) of dashboard-style modules since you get what you need out of admin_menu, but maybe if you stepped back and imagined yourself as a new Drupal user, there might be a glimmer of something useful in a search / favorites interface. If you're interested and have 3 minutes, the Navigate screencast I put together demonstrates a working prototype. It searches menu items using partial words and descriptions, which makes it pretty effective when looking for a menu item.
I'm starting to sound like I'm pushing search / favorites hard, but I guess I'm more defending it as a potential alternative interface, one that could use some user testing before it gets discarded. If you don't have a vote in keeping admin_menu out of core though, I don't know what hope there is for me to have a vote in this. ;)
Thanks for egging me on, I've had thoughts about making navigation easier for a while now, and have been looking for the chance to get them ground down into something more reasonable. Hope you don't mind the extensive responses, it's just nice to have to articulate to someone, and get smacked down a little. :)
Chris Shattuck
Learn Drupal with over 1700 Drupal video tutorials
...
Sorry, I'm a bit short on time, 'cause I have to get 2 projects up & running today.
Daniel F. Kudwien
unleashed mind
Daniel F. Kudwien
netzstrategen
Touche! I'll have to some
Touche! I'll have to some time reviewing the admin_menu issue queue to get a feel for where you're taking it, and I might be able to help with some patchwork. The other thing I'd want to put in my vote for is integrated user bookmarks (did I mention that already? ;) ), but I need to review admin_menu more and see if it's within the scope of your new infrastructure. Search / bookmarking is about 70% of the value I see in the Navigate module. Getting them into admin_menu - which is indeed a much less monstrous interface - would be, imo, a huge win.
In regards to my input the top-level admin re-categorization discussion (I assume you mean the discussion this forked from, http://groups.drupal.org/node/19171), there is a lot of input already from many intelligent folks, and I don't know if I'd have much to say about it yet, since I use search and bookmarking to get around Drupal most of the time. I've spent much more time on the interface problem than with the structural issues. It's good to see work being done on this front, though. As a side-effect, it seems like it's making people really articulate what Drupal does and what people do with it and I'm enjoying the resulting insights.
In regards to that break, here you go: http://drupal.org/node/331139#comment-1363810. I can't edit it myself because it uses an input filter I don't have permissions for.
Chris Shattuck
Learn Drupal with over 1700 Drupal video tutorials
Widgets!
Heya! Just watched your new screencast - great work! :)
Also wanted to give a quick heads up: Administration menu 3.x-dev becomes more and more stable. It contains many architectural improvements - one of the most important for this discussion being that it basically is a dumping ground for administrative widgets now - the menu being one of them (next to the icon menu on the left and user/actions links on the right).
So, from a high-level view, both Administration Menu and Navigate use a similar approach now. I did not look at Navigate's code yet, but I'd be especially interested in whether Navigate's widgets could be abstracted in a way, so they work with both UIs.
I think that this will definitely be the future: You have an administrative UI, mostly detached from the regular's site content, and that UI contains multiple widgets provided by modules to ease administration, but also apply custom/individual workflows of users (i.e. whatever makes sense to them). With regard to this, we'll see common/generic administrative widgets (such as favorites/bookmarks), but also module-specific widgets (such as a widget provided by Views UI to quickly access, add, and perhaps even alter views, or such as a content moderation widget provided by one of the moderation modules).
To get there, we'd have to start analyzing the common denominator for those widgets.
For Administration menu, I can already tell that we need to distinguish between static and dynamic widgets: Static widgets always contain the same content until the cache is flushed (such as the admin menu), and when the cache is flushed, a full rebuild happens. Dynamic widgets will probably store markers/pointers only, so they attach/inject themselves into the UI on each page request/load (possible examples would be a "pathway", i.e. a link list of the last 10 visited pages, or contextually displayed stuff for the current page, e.g. administrative tabs/local tasks of the current page).
Daniel F. Kudwien
unleashed mind
Daniel F. Kudwien
netzstrategen
Requirements for Administration menu in core
Requirements for Administration menu in core
Daniel F. Kudwien
unleashed mind
Daniel F. Kudwien
netzstrategen
BTW, I'd love to see admin
BTW, I'd love to see admin menu in core, I just don't want to stop the innovation there. Seems like we can do even better.
Chris Shattuck
Learn Drupal with over 1700 Drupal video tutorials
Make more things automatic:
Make more things automatic: I've lost count of the number of times I create a node, and want to give it a menu item, and for the item title I type the exact same title all over again.
There's also some redundancy between path and menu structure. More often than node, a node is going to sit at "about/team", and its menu item is going to be about >> team. We could do to have a tighter integration between path, menu, and breadcrumb -- I for one frequently find myself replicating the same structure in these.