Getting a better menu interface into core

chrisshattuck's picture

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

  1. Menu search - Ideally auto-complete style
  2. User-based menu bookmarks - Allow users to have their own set of bookmarks or favorites
  3. Collapsing menus with saved state - When using collapsible menus, state should be saved from one page to another

Comments

...

sun's picture
  1. Yes, in core.
  2. It can't, because each administration/navigation tool has different requirements for its "space". admin_menu, teleport, navigate modules all have different user interface concepts.
  3. Search, not limited to menus (see teleport module). However, I do not think something like teleport will make it into core anytime soon, because modules like teleport assume that the user already knows what he wants to find (meaning: Drupal core lingo, contributed modules lingo, menu item names, page names, etc).

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
unleashed mind

Thanks for your thoughts,

chrisshattuck's picture

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

sun's picture
  • When admin_menu's story began, I played around with the optimal location and also tried to stuff the menu into a vertical sidebar. However, that would have required to hide it and invoke/display it only on hover or some other trigger, because it took too many space on the page - which means slower access to something you literally need to access on every page. So there are different user interface requirements.
  • Upfront: I'm not really sure whether I really meant teleport module or another MacOS Finder clone. There are too many of them and I never needed anything else on top of admin_menu. However, your argument would be valid, if Drupal's search was able to index all kind of pages in a private admin search index, i.e. including forms, form elements and their values (which I doubt will happen anytime soon). Otherwise, you would not find the "Site information" settings page when you would search for "Site name". But even then, you would have to now upfront that Drupal calls it "site name" and not "homepage title". (Or just consider Panels' term of "panes"...)
  • Putting things into a hierarchy is especially important for beginners. Without a hierarchy, you have no way to explore the possibilities. With a bad hierarchy (the topic of the other discussion), you can explore, but you won't grasp it quickly.
  • Once you grasped the hierarchy, you already know where you want to go. No need to search for it. What counts is very fast access. This has always been the top priority of admin_menu's user interface (hence, no time-consuming, annoying UI effects). If that was not the case, a user might be faster by typing the URL via keyboard.
  • The last time I checked some of those administration dashboard/helper modules, none of them implemented proper support for extensibility and potential integration with 4000+ contrib modules. Also, some features of them could easily be implemented by re-using functionality of other modules (e.g. Bookmarks: Flag) instead of duplicating it. IMHO, all maintainers and developers of those modules should join forces to create a new, consolidated, extensible, customizable, and innovative admin dashboard/finder module. And TBH, I even played with the idea of creating a new sub-module in admin_menu to get it done (right).
  • I am not saying that admin_menu is the ultimate solution and 2.x is definitely not. However, 3.x will come with major improvements, which will allow pretty insane integration in contrib. Any "Move admin_menu into core" issue will get a -1 from me unless 3.x has been finished. Recent activities in and for Drupal core showed that my vote does not count though, so it might happen the wrong way.

Daniel F. Kudwien
unleashed mind

Daniel F. Kudwien
unleashed mind

Interesting to hear a bit on

chrisshattuck's picture

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

...

sun's picture

Sorry, I'm a bit short on time, 'cause I have to get 2 projects up & running today.

  • Note that I'm not arguing against search at all. It is a very valid and handy utility and there is a reason why Mac users love their Finder. (Disclaimer: I'm not a Mac user, but was impressed by Finder's capabilities as well as look & feel.)
  • I watched your screencast about Navigate right after you published it. :) However, that monstrous sidebar still scared me away. Aside from that it looked interesting. Completely off-topic here: Can you put a <--break--> tag on its project page before the embedded video, please?
  • Maybe this discussion is a kick-start for an even more awesome collaboration? The more I think about and work on admin_menu's architectural redesign in 3.x, the more I'm questioning why there could not be a Finder-alike search bar in a new admin_search module that may ship with admin_menu. You know, admin_menu is horizontal, a search field is horizontal... So, whuzzup? :)
  • Yeah, I can feel your pain. Talking with someone who cares about Drupal's administration and actually has a viable vision makes a lot (more) sense. I too have no one to discuss next generation architectural design decisions. But on that note - it seems I must have missed your feedback on the top-level admin re-categorization discussion? ;)

Daniel F. Kudwien
unleashed mind

Daniel F. Kudwien
unleashed mind

Touche! I'll have to some

chrisshattuck's picture

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!

sun's picture

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
unleashed mind

Requirements for Administration menu in core

Daniel F. Kudwien
unleashed mind

BTW, I'd love to see admin

chrisshattuck's picture

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:

joachim's picture

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.