Nav Menu: Auto-set the location if there's only one menu and one location

[bobbravo2]

Just finished testing 3.6-alpha-23451. Menus tested great in IE8+

IE7 Shows some CSS bugs: ​http://cl.ly/image/142s2y2Y452w Functionally speaking, IE7 works.
If we need to support IE7, let me know and I'll take a stab at the browser quirks.

One UX note is that the checkbox

feels unnecessary if (menus == 1 && theme_locations == 1)

The UX seems broken when I "Create Menu" on my fresh new WordPress site, and then go to the homepage and see the fallback pages menu. The 1 menu should automatically be used, and the checkboxes only shown when $menus > 1.

And because I'm a huge web geek, the menus in IE6: ​http://cl.ly/image/1P140s1K2r0f Thank the gods we don't have to support that anymore!

I tried applying the 23119.31.refresh.patch patch as well, but there were some missing files, let me know which one you'd like more testing on, or if I should just test trunk.

[DrewAPicture]

Replying to bobbravo2:

IE7 Shows some CSS bugs: ​http://cl.ly/image/142s2y2Y452w Functionally speaking, IE7 works.
If we need to support IE7, let me know and I'll take a stab at the browser quirks.

The rule of thumb with IE7, is ​not horribly broken.

One UX note is that the checkbox

feels unnecessary if (menus == 1 && theme_locations == 1)

The UX seems broken when I "Create Menu" on my fresh new WordPress site, and then go to the homepage and see the fallback pages menu. The 1 menu should automatically be used, and the checkboxes only shown when $menus > 1.

I disagree with hiding the locations at all, especially since we don't have the dedicated locations meta box anymore. Users need to be able to un-assign the one menu from the one location.

I tried applying the 23119.31.refresh.patch patch as well, but there were some missing files, let me know which one you'd like more testing on, or if I should just test trunk.

All accepted changes were committed from #23119 so we're testing on trunk.

See also: #23449, #23450

[bobbravo2]

Replying to DrewAPicture:

Replying to bobbravo2:

IE7 Shows some CSS bugs: ​http://cl.ly/image/142s2y2Y452w Functionally speaking, IE7 works.
If we need to support IE7, let me know and I'll take a stab at the browser quirks.

The rule of thumb with IE7, is ​not horribly broken.

Gotchya - I'll do some more testing - but it appears to be 100% functional.

I disagree with hiding the locations at all, especially since we don't have the dedicated locations meta box anymore. Users need to be able to un-assign the one menu from the one location.

What use case is this? Would this be a custom menu being used in a widget?
In any case - I think once you save your first menu, it should default to being enabled. Otherwise it's adding another step in an otherwise intuitive process.

I tried applying the 23119.31.refresh.patch patch as well, but there were some missing files, let me know which one you'd like more testing on, or if I should just test trunk.

All accepted changes were committed from #23119 so we're testing on trunk.

Great.

See also: #23449, #23450

[DrewAPicture]

Replying to bobbravo2:

I disagree with hiding the locations at all, especially since we don't have the dedicated locations meta box anymore. Users need to be able to un-assign the one menu from the one location.

What use case is this? Would this be a custom menu being used in a widget?
In any case - I think once you save your first menu, it should default to being enabled. Otherwise it's adding another step in an otherwise intuitive process.

I have no problem auto-setting the location if there's only one menu and one location, that seems like logical UX.

But we shouldn't hide the checkbox just because there's only one menu. This would mean the only way to unset the location would be to add a second menu which seems even more unintuitive to me.

[ocean90]

@bobbravo2
Please don't summarize multiple issues in one ticket. Lets separate them in different tickets. IE7 should be another ticket (but not really needed yet :)

[bobbravo2]

Replying to DrewAPicture:

Replying to bobbravo2:

I disagree with hiding the locations at all, especially since we don't have the dedicated locations meta box anymore. Users need to be able to un-assign the one menu from the one location.

What use case is this? Would this be a custom menu being used in a widget?
In any case - I think once you save your first menu, it should default to being enabled. Otherwise it's adding another step in an otherwise intuitive process.

I have no problem auto-setting the location if there's only one menu and one location, that seems like logical UX.

Awesome.

But we shouldn't hide the checkbox just because there's only one menu. This would mean the only way to unset the location would be to add a second menu which seems even more unintuitive to me.

Good point. I agree w/ you.

@ocean90
That's what I thought - do we need to support IE7? The only reason I mentioned it is to confirm that functionally it works - but isn't pretty.

[lessbloat]

In office hours on Monday, we decided to ​forgo auto-selecting the single theme location when adding a new menu from the "add new" screen.

A couple of notes:

• It is auto-selected if you go through the blank slate screen (when you have zero menus, and only one theme location)
• We decided to do it on the "add new" screen because users may be attempting to add a custom menu widget. Auto-selecting the theme location would only confuse them.