Revise Nav Menus based on wireframe testing

[ptahdunbar]

Working ticket for the revision of the new nav menu UI. See ​http://wpdevel.files.wordpress.com/2010/03/new-menus-wireframe.pdf

[voyagerfan5761]

Would this be a bad place to mention that I don't think tabs are a good way to present the menus?

I should qualify that: Tabs are alright if they can be side-scrolled like in Firefox, with buttons and/or the mouse wheel, but methinks that would add unnecessary JavaScript complexity.

[kretzschmar]

The new menu system lacks an option to add a link to the blog home. At least

wp_nav_menu()

should have the same "blog_home" option like

wp_page_menu()

.

[ryan]

Latest wireframes:

​http://wpdevel.files.wordpress.com/2010/04/menus-v002.pdf

[MadtownLems]

I apologize if this is not the right place for this feedback, as it might not be UI related, but I'm a little confused about getting around trac.

Can the menus tie into Theme Development better? For example, if I build a theme that has some tabs across the top, and another place with some buttons, and I'd like the Menu system to control what pages/posts/links appear in each of these menus, I run into a lot of trouble. How do I know what menu is supposed to go where?

I could require that if they want a menu to show up as Tabs, they need to name it Tabs. But that seems like a pretty poor idea.

I'd like my theme to be able to, say, register 2 menus. One of which is always displayed by my theme in one place, and another in another place. This doesn't really seem very easy to do with the current plan, especially in a MultiSite setup where I'm not building each blog.

Does this make sense?
Should it have gone somewhere else?
Is there already a good solution I just don't know? (crosses fingers)

[ryan]

Themes could register how many menus they support and pass a number to wp_nav_menu() indicating which of the x menus should be fetched. The numbers could be mapped to the user's menus. Text in the menus admin noting how many menus the current theme supports could be added. Not perfect, but it provides some mapping without every theme requiring a separate set of named menus.

[ryan]

A common request has been to make it easier to create a menu from existing pages or categories. I think the (+) tab is a good place to add this. A set of buttons or a button plus dropdown that allow populating the menu with "All Pages", "All Top Level Pages", "All Categories", what have you.

[jane]

+1 to ryan's request/suggestion.

[greenshady]

Replying to MadtownLems:

Can the menus tie into Theme Development better? For example, if I build a theme that has some tabs across the top, and another place with some buttons, and I'd like the Menu system to control what pages/posts/links appear in each of these menus, I run into a lot of trouble. How do I know what menu is supposed to go where?

I could require that if they want a menu to show up as Tabs, they need to name it Tabs. But that seems like a pretty poor idea.

I'd like my theme to be able to, say, register 2 menus. One of which is always displayed by my theme in one place, and another in another place. This doesn't really seem very easy to do with the current plan, especially in a MultiSite setup where I'm not building each blog.

Check if the menu exists. If not, create it:

if ( !is_nav_menu( 'super-duper' ) )
	wp_create_nav_menu( __( 'Super Duper' ), array( 'slug' => 'super-duper' ) );

Then, call that specific menu in your templates:

wp_nav_menu( array( 'menu' => 'super-duper' ) );

This is basically the same thing you'd do with creating sidebars for your theme.

[MadtownLems]

greenshady - thanks for the response, but there is at least 1 pretty big issue with that approach.

• If a user changes one of those menu's names, everything blows up. The theme will create yet another new menu and use that brand new menu in that part of the theme rather than the menu they had been using and probably customized.

[chrisbliss18]

I've been pondering this ticket for the past day. There is no information in this ticket to describe why we're going for this type of redesign.

Currently, with the options on the right-hand side, it creates a clean division between the admin menus, the menu structure, and the new menu options. The presented wireframe would just create a mess on the left-hand side for no good reason that I can see or imagine.

If this is one of the blockers for the inclusion of menus in 3.0, I say we dump it as it is a nonsensical redesign.

[nacin]

Actually flipping the columns is a few minutes of CSS. This isn't just a redesign. There are significant changes in functionality that need to happen for the component to be usable in the wild.

The presented wireframe makes sense from the UX perspective. I'm sorry you don't agree. It doesn't have to do with divisions, it has to do with usability and how the eyes and the mouse moves across the screen when the feature is being used.

It's been decided, and is no longer going to be debated. There is no information in this ticket because Trac is for code. These decisions were made by the UI team, the core team, the UX lead, etc., and reasoning was given extensively in numerous mediums, including on ​http://wpdevel.wordpress.com and in #wordpress-dev on IRC.

That all said, I will reiterate we have a long way to go in terms of code and features. That's why it's a blocker.

[chrisbliss18]

Information about what the trac ticket is actually about should be in the ticket as I was browsing for tickets on things to help with, saw this, and just had to guess as to the purpose.

So, I would recommend that if this is such a large blocker, that some links should be provided to help those that might want to help the project rather than keeping that information for those in the know.

I appreciate setting me on the right track. Are there any separate tickets that individually address what needs to be done, or is this the catch-all? Where can I best put my coding efforts without fear that I might be redoubling others' efforts that have yet to be submitted?

[nacin]

filosofo is working on a patch from the accessibility standpoint, which should be ready at some point today I think. That will drive the rest of the development.

Once that is in, we will try our best to identify distinct areas that need to be worked on. Per filosofo earlier today, he's "still trying to get the patch to a point where additional help will be constructive." There are various other tickets open in the Menus component but this will probably be ground zero.

Hovering in IRC might help -- I imagine a lot will be coordinated there over the weekend. Watch here for the commit, as that'll get a lot of it started.

Sometimes we forget that many of us are glued to a half-dozen different mediums and that our conversations kind of just move back and forth between them.

[jane]

What @nacin said. :)

@chrisbliss18: Instead of waiting to help with menus, why not try taking on a couple of discrete bugs? There are a bunch of people working on menus now, and the bugs are just as much of a blocker, if not more. If menus aren't ready by Monday, we're putting them in a plugin, but we need the bugs fixed to release.

[filosofo]

• OK, patch is against r14111, so I need to refresh.
• There are several known bugs (one really obvious) that I will knock out shortly, but I wanted to get the patch up. Give me an hour or so before you jump on the obvious bugs, and I'll post a refreshed, split patch.

[ryan]

(In [14248]) New menu UI. Props filosofo. see #12713

[filosofo]

Let's call this ticket closed as of [14248] and open new tickets according to specific issue.

[ryan]

(In [14248]) New menu UI. Props filosofo. see #12713