Menu Management UI
Here’s a quick preview of the new menu management admin page (still alpha stage).
It highlights the dropdown section, which is the only unfamiliar element. All the rest are borrowed from the widget management screen.
Feedback on the UI is very welcome, either here, or on the dedicated ticket: #11817.
Acts7, 
MadtownLems, and 19 others are discussing. 
Jane Wells 9:08 pm on January 17, 2010 Permalink
A couple of things. In the widget code, you can have multiple sidebars open. Here it looks like you can only have one open at a time, but it seems like it would make sense to be able to see them all at once. So the dropdowns adding to “the open menu” feels potentially awkward. Would the add have an automatic save, would the item need to be saved, would the menu need to be saved… what’s the ‘go live’ mechanism?
The dropdowns seem to perform the same function as “available menu items,” so am wondering of function of latter. Inactive menu items seems unnecessary, since it’s not like widgets where there might be a lot of custom code you want to hold on to.
In the menu items themselves, it’s cool you can change the display name, but there should definitely be a place in the there to show the actual page/category name so that users don’t wind up accidentally confusing themselves by renaming things.
Also, the dropdown
scribu 9:21 pm on January 17, 2010 Permalink
Looks like your comment was truncated.
Don’t really know how to tackle the “multiple open menus” problem, short of including the dropdowns in each menu.
Related to the available menu items section, I was thinking of putting all of them in a “Other items” dropdown.
Agree on the “inactive menu items” section: it will be removed.
I plan to include some sort of preview link for pages and categories, probably at the bottom of each widget.
Jane Wells 9:23 pm on January 17, 2010 Permalink
Hm, weird. Yes, looks like it was truncated, and can’t for the life of me remember what it said. I’m getting old!
scribu 9:58 pm on January 17, 2010 Permalink
You can have more than one menu open at one time and move items from one to the other. The dropdowns will just add elements to the first open one.
The menu is saved every time you add an item to it (from one of the dropdowns or otherwise), as well as when you rearange the existing items.
scribu 10:05 pm on January 17, 2010 Permalink
Maybe you could have a “menu assembly” spot:
You move the menu you want to work on to that spot and use the dropdowns to add elements to it, while still being able to interact with the other menus.
Shane 3:39 am on January 18, 2010 Permalink
I was just thinking the same thing. Just like Widgets where they sit there and you drag them over (The inactive section.) Then you can drag them over to the area’s in which you want to place it in.
Daryl Koopersmith 3:44 pm on January 18, 2010 Permalink
Some UI ideas in a similar vein… take them for what you will. (After I wrote this, I noticed that you mentioned that you were moving the “Available” section into a dropdown… I’ll post this anyway.)
Consistent UX:
1. Make the dropdowns collapsable and their contents draggable (like the “Available” section is now).
2. Or make the “Available” section a dropdown.
—I personally like option 1 more. Users could drag items to whichever menu they wanted. You could use it as a starting point to add a UI to select all children of a certain page, and it’s more in line with what users are used to (i.e. widget admin). It also could result in much fewer clicks for people who are building large menus.
Central Focus:
1. Move all items and dropdowns into one “Available Menu Items” section.
2. Or separate the dropdowns into their own sections: “Special Menu Items” (Home, Link), Pages, Categories, Bookmarks, etc.
—I think option 2 would potentially have a cleaner UI and be a better use of screen real estate. Why should we be cramming everything into a small selection menu?
Also, +1 to the idea to indicate when you’ve renamed a link to a page.
scribu 2:48 pm on January 21, 2010 Permalink
For all the people who are asking about nested menu items:
http://core.trac.wordpress.org/ticket/11817#comment:36
WordPress 3.0: Neues Menümanagment - Features, Eindruck, Funktion, Theme, Template-Tag, Screencast - WordPress Deutschland Blog 11:58 pm on January 17, 2010 Permalink
[...] Mit WordPress 3.0 wird das Menü im Administrationsbereich konfigurierbar sein. Ein kurzer Screencast gibt einen ersten Eindruck des neuen Features. Um diese Funktion nutzen zu können, muss im [...]
WordPress 3 – Admin-Bereich frei anpassbar » admin, anpassbar, bereich, feature, frei, panel, seiten, wordpress 3 » Digital Life 12:18 am on January 18, 2010 Permalink
[...] soll dieses Feature bereits in WordPress 3 enthalten sein. Allerdings steht im original Post zum Screencast nichts von einer Version. In wie weit man dies also als verlässlich ansehen kann, [...]
Ptah Dunbar 11:16 am on January 18, 2010 Permalink
How/Where are the actual menus created in the UI?
scribu 2:45 pm on January 21, 2010 Permalink
You mean in the theme?
It will probably be similar to how widgets are displayed – using a template tag:
dynamic_menu()
Ptah Dunbar 2:42 am on January 22, 2010 Permalink
No, in the backend. In the vid, you have “Menu 1″ and “Menu 2″, im assuming those auto appear after calling
register_menu()?scribu 7:57 am on January 22, 2010 Permalink
Yeah, it uses register_menu(). The patch in the ticket includes a modified functions.php file in the default theme.
Paul 2:24 pm on January 18, 2010 Permalink
Hi
Forgive ignorance. I know how to use trac and svn but was wondering if there is a known standard way to incorporate your .diff files for this menu functionality into the latest trunk? Or do we have to wait for it to be committed to the core. I am eager to play and test some theme ideas.
Many thanks!!
scribu 2:44 pm on January 21, 2010 Permalink
Read How to Submit Patches
It explains how to apply patches as well.
Paul 5:06 pm on January 21, 2010 Permalink
Thank You!
Paul 6:46 pm on January 21, 2010 Permalink
I was wondering whether there is a reason to limit the viewable items to 5? There is a lot of unused white space below the three columns. Why not have up to 20 viewable items so the average blog user will not need to scroll. And blogs with a lot of categories and pages will be a lot easier to manage, as more of the menu structure will be viewable at once. I believe this would enhance usability.
scribu 7:35 pm on January 21, 2010 Permalink
Since the size is set through JavaScript, we might as well resize them dynamically, by the number of items in each select, but no larger than 20, as you said.
Cristian Antohe 3:44 pm on January 18, 2010 Permalink
What about child pages and grand-child pages? There is no default way of doing this using the Widget UI.
I think the easiest way to do this is with a dropdown similar to the one you have to select pages. On each “menu element” from the right we have the possibility to select the Parent page. If we select one then the menu order should reorganized and the child menu item should be indented.
I hope this makes sense.
Carl Hancock 4:11 pm on January 18, 2010 Permalink
Is this going to support menu items that have a parent-child relationship (ex. drop downs)? Judging from the UI example above it isn’t there, but is it a planned feature?
Also, any plans for the functionality that the widget that can then display these menus will offer in the way of features? (ex. show all, only show children of current page for sub-navigation side nav, etc.).
scribu 4:17 pm on January 18, 2010 Permalink
“Why should we be cramming everything into a small selection menu?”
Because some sites will have 100 pages, 30 categories etc., which would take up a lot of screen space.
We need a more compact way of displaying items.
In the next version, each selection menu will show 5 items at a time, instead of 1.
Daryl Koopersmith 5:14 pm on January 18, 2010 Permalink
Ah, fantastic. That’s basically what I was getting at. Looks great!
Jason 4:51 pm on January 18, 2010 Permalink
Amazing! Thanks for the ‘sneak peak’
Steven 7:37 am on January 19, 2010 Permalink
Looks wicked!! Will this also include an option to create multi level menu structures?
Jean-Patrick Smith 9:37 am on January 19, 2010 Permalink
Pretty slick, I’m lovin it
WordPress 3.0 Development on Track | WordCast - Blogging news, WordPress help, WordPress plugins, WordPress themes, WordPress news 10:13 pm on January 21, 2010 Permalink
[...] Scribu gives a preview of the Menu Management UI with a screenshot and video. The new Menu Management panel in the WordPress Adminstration Panels give the user control over a new area in a WordPress Theme called the “Menus.” [...]
Flavio Paiva 11:37 pm on January 23, 2010 Permalink
This new feature will take WordPress to a higher level of personalization. I remember this resource from Joomla.
Paul 5:02 pm on January 25, 2010 Permalink
I am too new to leave this on the Trac in response to the latest screens. And even here I fear the ‘dunce’ syndrome coming on. But I just cannot help wondering why the new Menu Management could not be a Multiple Instance Widget, managed from the widget section. My reasoning is as follows:
.
1. Can use existing Registered Sidebars instead of additional Registered Menus in themes
2. That means one user of a theme can place a menu in a dynamic area, and another user of the same theme may place a widget.
3. Widgets are already established with menu-like features (Categories/Pages), so less learning curve for WP novices.
4. No need to create an additional admin interface.
Menu items could be represented by simple check boxes in the Widget Options panel.
I await the eggs (glad I went to school before kids were armed
scribu 5:07 pm on January 25, 2010 Permalink
I would agree with you, if it weren’t for those pesky “check boxes”.
It’s not easy to cram all the pages and all the categories in a tiny space, while at the same time making it easy to work with and allow the level of customisation that people want.
That’s why we’re going for a new admin page.
Paul 5:11 pm on January 25, 2010 Permalink
I see.
One last shot: What about placing the scrolling list/selection box you have designed, inside a widget. Keep the new method of selection, but wrap it in a familiar widget structure.
Paul 5:14 pm on January 25, 2010 Permalink
Ignore. I think you are right.
WooThemes WooNav Trumps Pagemash Plugin 3:48 pm on January 29, 2010 Permalink
[...] WordPress 3.0 is supposed to have menu admin coming in the next upgrade, however I am certain the new Woo Navigation will feel and look better. Don’t take my word for it? Just watch the screencast created by Magnus from WooThemes! There is more information and another screencast using their Delegate Theme like this one here too. [...]
Peter Wade 1:00 am on February 1, 2010 Permalink
Will the Menu Management 3.0 provide for external links (outside WP but same URL) to go into the menu? Or will this require a plugin?
sc0ttkclark 6:54 pm on February 2, 2010 Permalink
External Links are supported, as shown in the Demo Video as an option
The Exciting Future of WordPress! Part 2 | Fresh 6:05 pm on February 2, 2010 Permalink
[...] admin area, you will be able to create one or more menus and add any type of link you wish. The menu management screen looks virtually the same as widget management screen, and appears to work similarly too. Just call the menu you’ve created in your template, and [...]
Jess Planck 2:55 am on February 6, 2010 Permalink
It has to be one of the biggest requests I get: “I want to add a link to something into the where-ever menu” This will be so very useful.
I know a lot of the ui was taken straight from Widgets, and I can see how the open and close options for menu items would start getting cumbersome. Perhaps you can separate the ui for the menu organization and menu items by using a thickbox / colorbox instead. That might help with some performance and give users an interface to change a menu item properties.
For example: A user could visit Appearance > Menus and arrange the menu order. Then click a control for the “About” page item that would open a Thickbox / Colorbox widow where they then change the properties for that menu item to a Category Link and change the Link Text to “News”.
Alex M. 9:13 am on February 6, 2010 Permalink
-1
Lightboxes allow you to only edit one thing at a time, you can’t click elsewhere on the page, etc.
I see nothing wrong with the widget style UI.
Jess Planck 2:00 pm on February 6, 2010 Permalink
Yea, too true I don’t like the lightbox losing the rest of the screen interface.
The only place the Widget UI falls apart is if you go hierarchical or if you want to change menu content types. Perhaps (stealing from Media UI ideas) moving the menu item properties UI to a drawer or using a single UI for the properties.
I would not be opposed to the users I’ve dealt with having to focus on one menu item and one menu at a time. With some of the complex menus I’ve seen (and been forced to create) the end client desire has been more for quick arrangement of the hierarchy not menu item properties. They don’t have any idea the complex differences between a Page, Category, or Link. But they will get frustrated when they have to; 1. remove a the Category, 2. replace with a Link, & 3 THEN try to move that item to it’s final position.
I guess I should put up or shut up! If I’ve got time I’ll at lest put a wireframe on the ticket.
RJ 6:29 am on February 12, 2010 Permalink
I’m really excited for this to make its way into WP 3.0. Having worked with Joomla’s interface, it’s something that I feel makes WP a much friendlier and powerful “non-blog” CMS. Leaving menu management to a handful of experienced designers is one thing, but it’s another to bring it right into the hands of the least experienced end-user.
kathy 4:02 am on March 15, 2010 Permalink
umm that looks awesome. i was trying to figure out how to code something similar (if basic) that into an options page. can this be available already.
Michael 10:48 pm on April 6, 2010 Permalink
First, Love this – such an awesome leap.
Second, my only BIG issue with this is that (and maybe I’m missing something) the menu’s should not have to be enabled by the user – only managed by the user.
For example, as a theme designer, If I build a menu into my theme that’s great – but as a user, when I activate the theme, it doesn’t automatically create the menu. Two issues arise from this.
1. as a theme developer, If my user makes 4 menus, how do I control which menu goes where?
2. as a user, I have to manually create (and name correctly) my menus for them to show up in the proper places in the theme.
–
I see an simple solution to this, treat the menu management like you treat widget management.
Hopes this makes sense.
MadtownLems 6:36 pm on April 12, 2010 Permalink
This is the exact problem I’m hitting already. I’m all about coding custom menu displays into the themes; in fact, I’ve been doing this with my own (much simpler) UI backend for quite some time.
I need the ability to, when someone activates Theme X, to have it automatically create (register?) the necessary menus and let me hardcode displays of certain menus in certain places.
Is there any way to do this currently?
Acts7 6:09 pm on October 5, 2010 Permalink
Here’s what I just don’t get. Currently we have “Automatically Add Top Level Pages”
That REALLLY Needs to be the other way around.
As of right now, there is no benefit … when adding a new page … to being able to select the parent page.
If you select it… Its not in the menu.
Why is that?
Auto-Add a parent page … thats one easy click to add.
But if its children do not follow.
We have saved 3 seconds not adding one parent page.
But lose 100 seconds dragging all the children.
Menü-Management in WordPress 3.0 | black-forever 2:11 pm on November 19, 2010 Permalink
[...] wurde dort ein kleiner Screencast veröffentlich (Menu Management UI), der zeigen soll wie künftig die Verwaltung von Navigationen / Menüs in WordPress 3.0 [...]