WordPress.org

Make WordPress Core

Opened 16 months ago

Closed 14 months ago

Last modified 11 months ago

#23119 closed enhancement (fixed)

UX Improvements to nav-menus.php

Reported by: lessbloat Owned by:
Milestone: 3.6 Priority: normal
Severity: normal Version:
Component: Menus Keywords: 3.6-menus needs-codex
Focuses: Cc:

Description (last modified by lessbloat)

There are some UI issues with nav-menus.php that have been around for a while (like tabs being confusing for managing multiple menus).

Knowing this, we ran a couple of menus-based user tests hoping to find additional ideas for improvements.

Here's a list of potential enhancements that I'd like to test for 3.6:

A) Managing menus as tabs can be confusing. Sometimes users think the tabs represent the menu itself, and they'll create multiple menus by mistake (thinking the tabs represent menu items). Tabs also pose a problem, after you get 10+ menus. I'd like to test the idea of removing the tabs altogether. My thought was to add a "add menu" link next to the header (similar to other areas of the admin), and move menu selection to a drop down select box.

B) In the "add new menu" view, new users get confused as to what they are supposed to do. Both of the users we tested wanted to click the "Create Menu" button first (not noticing the menu name field). I'd like to test adding focus to the menu name field, and moving the "Create Menu" button closer to the name field (just for this add new screen).

C) The "theme locations" section appears to be semi-confusing to users. I'd like to test moving the functionality to the bottom of the page, and changing the formatting, so that it no longer matches the formatting of the rest of the left column, and perhaps changing the wording a bit.

D) I'd like to add an intro sentence which explains that menus can be used as custom navigation within your theme (we'd link to "theme locations" at the bottom of the page), or within widgets (adding a link to widgets). It will just be a quick, short sentence to introduce the concept of menus, while at the same time exposing the fact that menus can be used in widgets.

E) There's a lot of wasted space in the left column. Moving "theme locations" to the bottom of the page will free up a little space, but I'd like to see if there is anything else we can do to eliminate the need to scroll. I'd like to test changing the left column to an accordion (using jQuery UI). Thus eliminating a bunch of padding, and showing only one menu items options at a time. We'll test it and see how it performs.

F) When a user saves a change to "theme locations" it would be nice to give them a link to preview their new menu.

Once we complete some patches, we'll test these enhancements by re-running more users through the same set of user tests.

Attachments (53)

23119-A.diff (9.1 KB) - added by lessbloat 16 months ago.
23119-B.diff (10.2 KB) - added by lessbloat 16 months ago.
23119-C.diff (15.4 KB) - added by lessbloat 16 months ago.
23119-D.diff (15.7 KB) - added by lessbloat 16 months ago.
23119-E.diff (16.8 KB) - added by lessbloat 16 months ago.
23119-F.diff (17.7 KB) - added by lessbloat 16 months ago.
23119.6.diff (17.9 KB) - added by lessbloat 16 months ago.
23119.7.diff (2.0 KB) - added by lessbloat 16 months ago.
multilingual-menus.JPG (102.0 KB) - added by sooskriszta 16 months ago.
Multilingual menus
23119.8.diff (5.8 KB) - added by lessbloat 16 months ago.
23119.9.diff (6.4 KB) - added by lessbloat 16 months ago.
23119.10.diff (7.6 KB) - added by lessbloat 16 months ago.
23119.11.diff (22.0 KB) - added by lessbloat 16 months ago.
23119.12.diff (22.1 KB) - added by lessbloat 15 months ago.
23119.13.diff (23.1 KB) - added by lessbloat 15 months ago.
23119.14.diff (27.0 KB) - added by lessbloat 15 months ago.
Screen Shot 2013-01-10 at 3.16.42 PM.png (218.1 KB) - added by jkudish 15 months ago.
first implementation of WP_Menus_List_Table
23119.15.diff (33.5 KB) - added by jkudish 15 months ago.
first implementation of WP_Menus_List_Table
23119.16.diff (36.8 KB) - added by jkudish 15 months ago.
23119.17.diff (36.7 KB) - added by lessbloat 15 months ago.
Screen Shot 2013-01-11 at 5.23.30 PM.png (19.8 KB) - added by keoshi 15 months ago.
Title attribute outside metabox
23119.18.diff (38.6 KB) - added by lessbloat 15 months ago.
23119.18.1.diff (34.1 KB) - added by DrewAPicture 15 months ago.
Copy change on updated msg + numbered specifiers
23119.19.diff (42.4 KB) - added by lessbloat 15 months ago.
23119.20.diff (42.5 KB) - added by DrewAPicture 15 months ago.
+ common links filter
23119.21.diff (47.7 KB) - added by lessbloat 15 months ago.
23119.22.diff (49.2 KB) - added by lessbloat 15 months ago.
23119.23.diff (49.5 KB) - added by lessbloat 15 months ago.
23119.24.diff (51.7 KB) - added by jkudish 15 months ago.
theme locations as checkboxes
Screen Shot 2013-02-05 at 10.43.19 PM.png (202.3 KB) - added by jkudish 15 months ago.
theme locations as checkboxes screenshot 1
Screen Shot 2013-02-05 at 10.43.33 PM.png (188.2 KB) - added by jkudish 15 months ago.
theme locations as checkboxes screenshot 2
demo_theme_locations.php (251 bytes) - added by DrewAPicture 15 months ago.
Demo Plugin: Adds 3 theme locations
nav-menu-patch.png (14.4 KB) - added by toscho 15 months ago.
23119.24.diff in latest trunk
23119.24.1.diff​ (54.5 KB) - added by lessbloat 15 months ago.
23119.25.diff (60.5 KB) - added by lessbloat 15 months ago.
23119.26.diff (60.8 KB) - added by jkudish 15 months ago.
improve menu saving code and fix saving bug
23119.27.diff (61.6 KB) - added by DrewAPicture 15 months ago.
Menu locations in dropdown
23119.28.diff (61.5 KB) - added by jkudish 15 months ago.
improves 23119.27.diff by removing an unneeded foreach loop
23119.28.1.diff (61.5 KB) - added by DrewAPicture 15 months ago.
Spacing issues in the foreach changes in 23119.28
23119.28.2.diff (62.6 KB) - added by DrewAPicture 15 months ago.
More complete docs for newly-introduced functions
23119.28.3.diff (62.9 KB) - added by DrewAPicture 15 months ago.
Limits locations in the dropdown to default 3 w/ filter.
23119.28.4.diff (63.0 KB) - added by DrewAPicture 15 months ago.
no-js CSS tweaks.
23119.29.diff (60.1 KB) - added by lessbloat 14 months ago.
23119.29.1.diff (59.8 KB) - added by lessbloat 14 months ago.
23119.29.2.diff (59.9 KB) - added by DrewAPicture 14 months ago.
Coding standards for new stuff, 6-digit hex codes in CSS colors, etc.
23119.29.3.diff (59.5 KB) - added by lessbloat 14 months ago.
23119.30.diff (61.4 KB) - added by jkudish 14 months ago.
code reviewed
23119.31.diff (61.6 KB) - added by lessbloat 14 months ago.
23119.31.refresh.diff (61.6 KB) - added by lessbloat 14 months ago.
23119.diff (60.7 KB) - added by aaroncampbell 14 months ago.
23119.2.diff (60.6 KB) - added by DrewAPicture 14 months ago.
refresh 23119.diff (fuzz)
23119.3.diff (552 bytes) - added by jkudish 14 months ago.
fixes php notices
23119.4.diff (1.1 KB) - added by jkudish 14 months ago.
fix missing select/dropdown of menus which was causing some menus to be invisible

Change History (295)

comment:1 lessbloat16 months ago

  • Description modified (diff)

lessbloat16 months ago

comment:2 lessbloat16 months ago

23119-A.diff is in the same vein as #22991, but it:

  • Eliminates all of the tab code (PHP, JS, & CSS)
  • Adds a "add new" button next to the header text
  • Auto-redirects on drop down selection

It looks like this:

http://f.cl.ly/items/082o1h0b0c3k361M1d28/23119-A.jpg

Note: The blank gap to the left of the new drop down will be filled by the intro sentence in D.

Last edited 16 months ago by lessbloat (previous) (diff)

lessbloat16 months ago

comment:3 lessbloat16 months ago

23119-B.diff​ includes A and:

  • Puts focus on the menu name field on page load (only for the add new view)
  • Brings the "Create Menu" button next to the menu name field and tightens things up for this view

Looks like this:

http://f.cl.ly/items/3k1r2T1l0b1i3Z211i0t/23119-B.jpg

lessbloat16 months ago

comment:4 lessbloat16 months ago

23119-C.diff​ includes B and:

  • Removes the "Theme Locations" meta box
  • Moves the "Theme Locations" functionality to the bottom of the page
  • Reformats the "Theme Locations" section so that it no longer looks like the rest of the left hand menu options.
  • Reworded "Theme Locations" as "Select menus for your theme" (copy suggestions welcome :-)).

Looks like:

http://f.cl.ly/items/2f0b0V0h2s3k1x382v3T/23119-C.jpg

comment:5 MikeHansenMe16 months ago

  • Cc mdhansen@… added

I like the idea of using a select field in place of the text input and have an option to "add new" which then shows the text input with the create menu and a cancel button(to switch back to the select). I can create an example if anyone else is interested in this approach.

lessbloat16 months ago

comment:6 lessbloat16 months ago

23119-D.diff​ includes C, and adds an intro sentence (again copy suggestions welcome).

Looks like:

http://f.cl.ly/items/3Z3S3p1U3f2K280m2L1g/23119-D.jpg

comment:7 helen16 months ago

#22991 for the menu select.

comment:8 DrewAPicture16 months ago

  • Cc xoodrew@… added

lessbloat16 months ago

comment:9 lessbloat16 months ago

23119-E.diff​ includes D, and turns the existing meta boxes into an accordion. I hacked it together with a few lines of JS and CSS. I chose to do it this way rather than mess with jQuery accordion, because all I'm really concerned with at this point is testing the concept. We'll test this version with some additional users and see how it performs (then we can come back and review the best way to handle this).

Looks like:

http://f.cl.ly/items/2M1b0m2R0T0H3E450P3Y/23119-E.jpg

lessbloat16 months ago

comment:10 lessbloat16 months ago

23119-F.diff​ includes E, and adds a notification message when you select a menu for your theme that includes a link to preview your changes.

Looks like:

http://f.cl.ly/items/272Q2r2M0A3b0v3K360a/23119-F.jpg

I'll run a couple users through these changes Monday, and post the results to the Make UI P2.

Feedback (and code reviews) welcome and very much appreciated.

Last edited 16 months ago by lessbloat (previous) (diff)

comment:11 toscho16 months ago

  • Cc info@… added

Some nice ideas! I like it.

Setting the focus on load into the input field looks like a useful addition. But what happens when the user is just exploring the UI, looking for something else? It is quite a long way to get back to the left hand navigation without a mouse.

The new menu input could be a datalist, so we can select a menu to edit without going down the whole page.

Oh, and I think Pages should be the top box on the left hand.

Last edited 16 months ago by toscho (previous) (diff)

lessbloat16 months ago

comment:12 lessbloat16 months ago

23119.6.diff​ adds:

  • localization functions
  • blank-slate view when user has no menus

comment:13 mercime16 months ago

  • Cc mercijavier@… added

lessbloat16 months ago

comment:14 lessbloat16 months ago

This morning, I ran two more users through the same set of user tests as the first two users (from a week ago). From the above patches, B was the only only one that stood out as a clear improvement to me. I've reverted A, C, D, E & F in 23119.7.diff​.

Next, I'll post another series of diffs based on observations from all 4 user tests, and then I'll test them again by running two more users through. We'll keep at it until we've smoothed over all of the rough parts.

comment:15 aaroncampbell16 months ago

  • Cc aaroncampbell added

sooskriszta16 months ago

Multilingual menus

comment:16 follow-up: sooskriszta16 months ago

Fundamentally a good idea to improve UI. Please keep multilingual installations in mind too while designing new UI.

Screenshot of current multilingual UI attached.
Multilingual menus

comment:17 in reply to: ↑ 16 ; follow-up: helen16 months ago

Replying to sooskriszta:

Please keep multilingual installations in mind too while designing new UI.

Since multilingual support is enabled via any number of plugins, and not built into core itself, I'm not sure how much if anything we can do to anticipate what plugins might or might not do to that screen.

comment:18 travisnorthcutt16 months ago

  • Cc travis@… added

I think this all looks great! Very nice. My only (very, very minor) quibble with C is that I think the theme location settings should only be moved to the bottom if E is also done, so that the theme location settings aren't pushed way down on the page.

comment:19 in reply to: ↑ 17 sooskriszta16 months ago

Replying to helen:

Replying to sooskriszta:

Please keep multilingual installations in mind too while designing new UI.

any number of plugins...not sure ... anything we can do to anticipate what plugins might ...do to that screen.

I guess what I am asking is for you to look at the current behavior of the most popular plugin (WPML) or two (WPML, qTranslate) and extrapolate if possible.

Also I assume there might be more details about the under-development core functionality http://wordpress.org/extend/ideas/topic/multiple-languages-blogging-a-core-solution available to you than are to us.

Anyway, I don't want to hijack this discussion and if this is not relevant then I apologize.

comment:20 sennza16 months ago

  • Cc bronson@… added

comment:21 husobj16 months ago

  • Cc ben@… added

lessbloat16 months ago

comment:22 follow-up: lessbloat16 months ago

23119.8.diff​ focuses on improving copy, including:

Simplifying copy on the initial (and add new) screen from three sentences to one:

http://f.cl.ly/items/2U000O001m093n1t2V0C/menus-copy-1.jpg

Changing "Theme Locations" to "Menus within your theme", and simplifying the copy in that meta box

http://f.cl.ly/items/12130V0u2v0r2B2R222A/menus-copy-2.jpg

Adding a line about dragging, and more info after items have been added to a menu:

http://f.cl.ly/items/3g2I2F3Y063A2V2w3E0j/menus-copy-3.jpg

Thoughts?

comment:23 follow-up: toscho16 months ago

The shorter initial description looks very good.

I think the line Automatically add … makes too much noise at its current position. Maybe set it below the input field and align both? Not sure how that works with translations.

Please, please move the most used metabox Pages to top.

lessbloat16 months ago

comment:24 lessbloat16 months ago

23119.9.diff​ adds a simple fade in effect to items when they are added to a menu (one user didn't notice where the menu item went after he saved it). It also adds a slideDown effect to the yellow message bar (just something I'd like to test).

comment:25 in reply to: ↑ 23 ; follow-up: lessbloat16 months ago

Replying to toscho:

Please, please move the most used metabox Pages to top.

I'm not totally against it. My only reservation is that by swapping the two, you no longer see both meta boxes at smaller resolutions. Currently you see "pages" peeking out at the bottom (making it more discoverable):

http://f.cl.ly/items/1c0n3d2Q201C1p1u1R06/pages-order1.jpg

But if you swap the two, you only see:

http://f.cl.ly/items/0e1A1j29473y000V1A1f/pages-order-2.jpg

Last edited 16 months ago by lessbloat (previous) (diff)

lessbloat16 months ago

comment:26 lessbloat16 months ago

23119.10.diff adds a "sub menu" description to menu items that are dragged to any sub menu position. A couple of the users didn't really understand why the menu items could be dragged there. Hopefully this will provide a bit more clarity:

http://f.cl.ly/items/1N0w3O1z22432S1z0x2J/sub-menu-item-desc.jpg

Last edited 16 months ago by lessbloat (previous) (diff)

comment:27 follow-up: helen16 months ago

Not sure "sub menu" is really quite right - I think it implies a display style, which might or might not be true in a given use. The concept of hierarchy is a little more of a complex one, but the help text should probably indicate "order and hierarchy" or some such.

comment:28 in reply to: ↑ 27 ; follow-up: lessbloat16 months ago

Replying to helen:

Not sure "sub menu" is really quite right - I think it implies a display style, which might or might not be true in a given use. The concept of hierarchy is a little more of a complex one, but the help text should probably indicate "order and hierarchy" or some such.

I see what you mean. How about "sub item", or "sub menu item"?

comment:29 in reply to: ↑ 25 husobj16 months ago

Replying to lessbloat:

Replying to toscho:

Please, please move the most used metabox Pages to top.

I'm not totally against it. My only reservation is that by swapping the two, you no longer see both meta boxes at smaller resolutions. Currently you see "pages" peeking out at the bottom (making it more discoverable):

I think it makes sense to keep Pages second so you can see multiple boxes.
If you then minimise the custom box it should remember that so Pages will move higher.

comment:30 in reply to: ↑ 28 ; follow-up: helen16 months ago

Replying to lessbloat:

I see what you mean. How about "sub item", or "sub menu item"?

"sub item" is certainly more accurate, although I'm going to play devil's advocate and wonder if we're wandering too far into trying to teach the concept of web navigation as a bulleted list with hierarchy via text on the menu screen :)

comment:31 in reply to: ↑ 30 lessbloat16 months ago

Replying to helen:

"sub item" is certainly more accurate, although I'm going to play devil's advocate and wonder if we're wandering too far into trying to teach the concept of web navigation as a bulleted list with hierarchy via text on the menu screen :)

I'll try it out on a couple of users and see if they even notice it.

comment:32 travisnorthcutt16 months ago

Huge +1 to "Menus within your theme" or similar language. I think that'll be much easier to grok for most people.

comment:33 follow-up: mmuro16 months ago

I believe that removing the tabs for listing all menus is necessary here.

What about a "New Menu" screen that has the most basic needs for a menu? Name, theme location, etc. Lots of room for help text. Creating the menu takes you to the menu manager page. This is more in line with a completely new menu than a submenu, though, and I doubt core devs would want to break it out of the Appearances menu.

If not that, an alternative is to use a Manage Menu/New Menu nav tab exactly like the Themes menu.

Removing the noise from what's needed to "build an existing menu" vs. "create a new menu" is what I'm getting at.

comment:34 in reply to: ↑ 22 ; follow-ups: saracannon16 months ago

  • Cc sararcannon@… added

The dragging/ordering verbiage takes up quite a bit of space for seasoned users (a whole menu item can practically fit there) - maybe we can intro-tooltip some of the menu directions for first time users?

also: any thoughts on collapsable submenus?

Replying to lessbloat:

23119.8.diff​ focuses on improving copy, including:

Adding a line about dragging, and more info after items have been added to a menu:

http://f.cl.ly/items/3g2I2F3Y063A2V2w3E0j/menus-copy-3.jpg

Thoughts?

comment:35 in reply to: ↑ 34 husobj16 months ago

Replying to saracannon:

The dragging/ordering verbiage takes up quite a bit of space for seasoned users (a whole menu item can practically fit there) - maybe we can intro-tooltip some of the menu directions for first time users?

Or maybe that line can appear below the menu items?
If you add lots of menu items it will obviously be off the page but people should have seen it before that as they start adding items - unless it's a first time user editing an large existing menu I guess.

comment:36 jkudish16 months ago

  • Cc jkudish added

comment:37 melchoyce16 months ago

  • Cc melissachoyce@… added

comment:38 jaredatch16 months ago

  • Cc jared@… added

comment:39 in reply to: ↑ 33 ; follow-ups: lessbloat16 months ago

Replying to mmuro:

I believe that removing the tabs for listing all menus is necessary here.

What about a "New Menu" screen that has the most basic needs for a menu? Name, theme location, etc. Lots of room for help text. Creating the menu takes you to the menu manager page.

Riffing on this. What about something like:

http://f.cl.ly/items/402U3L421g1l3M2Y0Q2z/menus.v4.png

Using WP_List_Table to list the menus instead of tabs.

Thoughts?

comment:40 in reply to: ↑ 39 toscho16 months ago

Replying to lessbloat:

Using WP_List_Table to list the menus instead of tabs.

Oh, I like it. Easy to learn and to extend. And useful if need many menus, like in the case of one menu per language as mentioned earlier.

comment:41 jkudish16 months ago

I really like the WP_List_Table approach

comment:42 in reply to: ↑ 39 ; follow-up: mmuro16 months ago

Replying to lessbloat:

Replying to mmuro:

I believe that removing the tabs for listing all menus is necessary here.

What about a "New Menu" screen that has the most basic needs for a menu? Name, theme location, etc. Lots of room for help text. Creating the menu takes you to the menu manager page.

Riffing on this. What about something like:

Using WP_List_Table to list the menus instead of tabs.

Thoughts?

That's a good start. The theme location/menu assignment underneath the WP_List_Table class seems out of place, though. Would this make better sense as maybe a third column on the menu screen? Plus, that'll make it a sortable to help those with lots of meta boxes.

Last edited 16 months ago by lessbloat (previous) (diff)

comment:43 jkudish16 months ago

That's a good start. The theme location/menu assignment underneath the WP_List_Table class seems out of place, though. Would this make better sense as maybe a third column on the menu screen? Plus, that'll make it a sortable to help those with lots of meta boxes.

Not sure how well that would work since you can only assign a single menu to a location, it might make for a really awkward UI to have that assignment be in the list of menus

comment:44 in reply to: ↑ 42 ; follow-up: lessbloat16 months ago

Replying to mmuro:

The theme location/menu assignment underneath the WP_List_Table class seems out of place, though. Would this make better sense as maybe a third column on the menu screen? Plus, that'll make it a sortable to help those with lots of meta boxes.

I don't think so. The theme location drop down allows you to select from multiple menus, which tells me it belongs on the menu management screen, not the add/edit screen (which should be all about a single menu). It always felt out of place to me in at the top of the add menu items column.

comment:45 in reply to: ↑ 44 mmuro16 months ago

Replying to lessbloat:

I don't think so. The theme location drop down allows you to select from multiple menus, which tells me it belongs on the menu management screen, not the add/edit screen (which should be all about a single menu). It always felt out of place to me in at the top of the add menu items column.

That's fair. I think you can make the menu mangement screen two column with the menu assignment on the left. With the WP_List_Class and it's paging/screen options, it could be pushed way down the page.

comment:46 zoonini16 months ago

  • Cc zoonini added

comment:47 DrewAPicture16 months ago

I like the idea of using WP_List_Table for the menus and even still having the theme location metabox adjacent to it.

Has anyone considered maybe capitalizing on the post edit UI for menu editing as we similarly did for media editing in 3.5? Title becomes menu name, the metaboxes column could hold the "add menu item" metaboxes, etc. Just a thought.

comment:48 in reply to: ↑ 34 helen16 months ago

Technically speaking, this is a little bit different than attachments - a menu is a taxonomy term, and each nav menu item is a post in that post type associated with that taxonomy term (both the taxonomy and post type being non-exposed/non-public). Not saying that it's not an idea worth pursuing - just noting that it'd be more involved than what was done in 3.5 for the attachment post type.

Replying to saracannon:

also: any thoughts on collapsable submenus?

Total wish list item: collapsible and draggable branches. No idea about the feasibility or difficulty, so just a wish for now :)

comment:49 JerrySarcastic16 months ago

  • Cc fittingsites@… added

comment:50 DrewAPicture16 months ago

Replying to helen:

Technically speaking, this is a little bit different than attachments - a menu is a taxonomy term, and each nav menu item is a post in that post type associated with that taxonomy term (both the taxonomy and post type being non-exposed/non-public).

Oh, it's definitely a little bit different :)

The main reasoning I bring up a split UI is twofold:

  1. The UI as-is is cluttered and doesn't have a clear primary purpose. Currently, it's used for creating and managing menus as well as assigning menu locations. It's a vacuum-packed approach that is both difficult to organize and emphasize priority.
  1. A split UI allows for prioritizing the screens' purpose. A screen for managing menus and locations, a screen for editing the menus. The latter screen is familiar to people because it's re-used all over the Dashboard.

comment:51 lachlanj16 months ago

  • Cc lachlan@… added

comment:52 DrewAPicture16 months ago

It occurs to me that a split-UI approach should not be outside the realm of possibility but two unique pages should; that's another menu item under Appearance.

What about a stepped approach similar to how the WP-Table Reloaded plugin handles it? A management screen leads to a table-editing screen and you're given two buttons: "Update Changes" and "Save and go back".

So in this context you could have "Save Menu" and "Manage Menus" on the menu-editing step.

comment:53 richardmtl16 months ago

  • Cc richardmtl added

comment:54 lessbloat16 months ago

23119.11.diff is a quick and dirty prototype of the concept in comment:39. I'll run a few users through this approach, and post results to the Make UI P2.

At a glance it looks like this:

http://f.cl.ly/items/402l1I1T3D1D2A282V3X/23119.11-1.jpg

http://f.cl.ly/items/2G3N2s2g2b0N3o2f3c1q/23119.11-2.jpg

http://f.cl.ly/items/0V1P300C131m0p1A0I2H/23119.11-3.jpg

Again, this is not committable code, just a quick proof of concept.

lessbloat16 months ago

comment:55 follow-ups: travisnorthcutt16 months ago

Would there be any support for breaking Menus out of the Appearance section? I've often thought that would make sense, seeing as how menus are essentially pieces of content, much like posts, pages, comments, other post types, etc. That would support using a UI similar to those other pieces of content (All Menus, Add New).

comment:56 lessbloat16 months ago

Here are some notes for two new users testing the changes proposed in comment:54.

Overall, I think this looks like a good direction. I'd love to hear your thoughts.

Last edited 16 months ago by lessbloat (previous) (diff)

comment:57 in reply to: ↑ 55 cliffseal16 months ago

Replying to travisnorthcutt:

Would there be any support for breaking Menus out of the Appearance section? I've often thought that would make sense, seeing as how menus are essentially pieces of content, much like posts, pages, comments, other post types, etc. That would support using a UI similar to those other pieces of content (All Menus, Add New).

I was literally just thinking this. I know it would add to the 'noise' on the left-hand menu, but it would also fix the awkward tabs for manage/new.

comment:58 in reply to: ↑ 55 JerrySarcastic16 months ago

Replying to travisnorthcutt:

Would there be any support for breaking Menus out of the Appearance section? I've often thought that would make sense, seeing as how menus are essentially pieces of content, much like posts, pages, comments, other post types, etc. That would support using a UI similar to those other pieces of content (All Menus, Add New).

+1 for moving Menus out of Appearance. With a split UI it just makes more sense, avoids the problem users have with tabs on the Menu configuration page, works with the existing UI conventions for the Dashboard, etc.

Plus, Menus has always felt *buried* in there; most new users are unaware of this tool until I point it out, so I'm sure this is a pain point for a lot of new users.

Last edited 16 months ago by JerrySarcastic (previous) (diff)

comment:59 in reply to: ↑ 55 ; follow-ups: lessbloat16 months ago

Replying to travisnorthcutt:

Would there be any support for breaking Menus out of the Appearance section?

My worry with this would be, how often do you customize menus? My guess is that many (dare I say most) users will do it once to add menus while first customizing their site, and then only very occasionally revisit to make small changes. So, while conceptually it make sense (since there is both a management screen, and an add/edit screen), I'm still not certain it warrants a spot in the main nav.

Thoughts?

comment:60 in reply to: ↑ 59 ; follow-up: DrewAPicture16 months ago

I agree with @lessbloat on leaving it as-is under Appearance. We can have two screens (two files, whatever) without needing two menu items. And as @helen points out, menus aren't your fly-by-night average post type, in fact they are a taxonomy.

I would however still argue for 2 separate files (the same as how we handle the two tabs in Appearance > Themes), but that's mostly because it's easier to do targeted help tabs without having to stuff them full of two screens' information.

comment:61 in reply to: ↑ 59 JerrySarcastic16 months ago

Replying to lessbloat:

My worry with this would be, how often do you customize menus? My guess is that many (dare I say most) users will do it once to add menus while first customizing their site, and then only very occasionally revisit to make small changes. So, while conceptually it make sense (since there is both a management screen, and an add/edit screen), I'm still not certain it warrants a spot in the main nav.

Thoughts?

That's a fair argument; I don't know any users that change this once it's been set up, except maybe occasionally.

comment:62 in reply to: ↑ 60 lessbloat16 months ago

Replying to DrewAPicture:

I would however still argue for 2 separate files (the same as how we handle the two tabs in Appearance > Themes), but that's mostly because it's easier to do targeted help tabs without having to stuff them full of two screens' information.

Sounds fine by me. The converse however is that you then have two pages with very similar markup. Anyone else want to weigh in on this?

Last edited 16 months ago by lessbloat (previous) (diff)

comment:63 mmuro16 months ago

Extending the WP_List_Class will require it's own file anyways. I think the switching of tabs can be done with one file.

comment:64 sabreuse16 months ago

  • Cc sabreuse added

comment:65 btvillarin16 months ago

  • Cc btvillarin added

lessbloat15 months ago

comment:66 lessbloat15 months ago

23119.12.diff​ takes the user back to the "add" screen if they delete a menu, and there are no other menus vs. just showing them an empty manage menus table.

comment:67 lessbloat15 months ago

Also, as a heads up @jkudish is working on transitioning my hacky menu management table (in 23119.11.diff) to use WP_List_Table.

comment:68 lessbloat15 months ago

23119.13.diff​ adds a couple links to the "menu updated" message (showing users what they can do with their newly saved menu):

http://f.cl.ly/items/2a0g3g2L3U021a3o2l2Y/use-this-menu.jpg

It also adds a message when users save "menus within your theme" with a link to preview their changes.

http://f.cl.ly/items/060c2p2l15463E2P1W3w/menus-within.jpg

lessbloat15 months ago

lessbloat15 months ago

comment:69 lessbloat15 months ago

23119.14.diff​:

  • Adds a new "Common Links" meta box with "home", and "log in" for starters. This is hacked in (I'm just anxious to test it), so if you can think of a better way to add it (perhaps make it more extensible) I'm all ears.
  • Re-organizes the meta boxes on the "add/edit" screen, so now it's: (Pages, Common Links, Custom Links, Categories) by default.
  • Changed "Label" under "Custom Links" to "Link Text". We'll test this and see how it performs.

Here's what it looks like:

http://f.cl.ly/items/0o2y2W3f1V2W3W0f3t0a/common-links.jpg

Thoughts?

jkudish15 months ago

first implementation of WP_Menus_List_Table

jkudish15 months ago

first implementation of WP_Menus_List_Table

comment:70 follow-ups: jkudish15 months ago

  • Keywords has-patch needs-testing added

23119.15.diff builds upon 23119.14.diff and converts the "hacked up" table into a proper WP_List_Table, which gives it several features:

  • search
  • items per page + paging
  • bulk actions
  • cleaner code to maintain / easier extendability

Here's how it looks now. Note that I chose that location for the search bar because I thought it would be a better spot for it vs. above the table. Up for debate of course.

http://core.trac.wordpress.org/raw-attachment/ticket/23119/Screen%20Shot%202013-01-10%20at%203.16.42%20PM.png

Implementation notes:

I pretty much went with an approach of the least modified code possible to integrate the WP_List_Table. There's definitely more work to be done:

  • I suggest we split the two tabs into 2 separate files, this will allow us to cut down on the amount of logic/if statements to display the different UI elements and will make updates easier
  • There's cleanup to be done with some (now) old code, assuming core adopts this new UI.

Thoughts so far?

Last edited 15 months ago by jkudish (previous) (diff)

comment:71 follow-up: jkudish15 months ago

@lessbloat: some thoughts on 23119.14.diff:

What other links do you imagine under "Common Links"? Do you expect this to auto-populate with actual frequently-used links as users add items to their menus? Or is it just meant to be a specially-curated list of links?

If the latter, then I suggest that we rename it to something different, as "common" suggests to me that they would be links I've inserted before. Also, wonder if anyone has extra suggestions as for links to add in there? Seems silly to have that meta box for just 2 links. Then again we should make it extensible for plugin developers to add their own links in here.

comment:72 jkudish15 months ago

I realized that deleting doesn't work (yet) neither from the action button (on hover) nor as a bulk action. I will fix it later today and submit an updated patch.

comment:73 in reply to: ↑ 70 SergeyBiryukov15 months ago

Replying to jkudish:

Note that I chose that location for the search bar because I thought it would be a better spot for it vs. above the table. Up for debate of course.

I guess above the table would be more intuitive and consistent with the other list tables.

comment:74 in reply to: ↑ 70 DrewAPicture15 months ago

Replying to jkudish:

I like the added search bar on top of the menu location meta box, but now that it's there, I wish both of them were on the other side of the list table, e.g. 2col:1col vs 1col:2col.

The search box seems confusing to me when visually paired with the metabox because the list table is what's going to change if you search for something. And actually, what would the workflow be if you searched? Does it just filter down the list table view?

I haven't poked into 23119.14 yet, so just wondering about row actions. Has there been discussion about what row actions we might want for the list view?

jkudish15 months ago

comment:75 follow-up: jkudish15 months ago

Replying to SergeyBiryukov:

And actually, what would the workflow be if you searched? Does it just filter down the list table view?

Yes, that's correct, it uses the s paramater from wp_get_nav_menu_items which trickles down to get_terms and performs a %search_term% LIKE query.

Reply to DrewAPicture

I haven't poked into 23119.14 yet, so just wondering about row actions. Has there been discussion about what row actions we might want for the list view?

For now the only row actions are 'Delete' and 'Edit'. lessbloat suggested adding a duplicate function, but that should be a separate ticket and would involve extra API work to allow duplicating menus.

In 23119.16.diff:

  • Deletion and bulk deletion now works.
  • Search now only appears if there are more than X number of menus, where X is currently set to 20 (which is the default per_page value). This value is filterable by plugins of course.
  • Search bar (when visible) now appears above the table, for consistency's sake.
  • Some code-cleanup but there's still lots of that to do.
Last edited 15 months ago by jkudish (previous) (diff)

comment:76 in reply to: ↑ 75 lessbloat15 months ago

Replying to jkudish:

In 23119.16.diff:

  • Deletion and bulk deletion now works.
  • Search now only appears if there are more than X number of menus, where X is currently set to 20 (which is the default per_page value). This value is filterable by plugins of course.
  • Search bar (when visible) now appears above the table, for consistency's sake.
  • Some code-cleanup but there's still lots of that to do.

Awesome stuff jkudish! I'll kick off another round of user tests tomorrow.

comment:77 follow-ups: grahamarmfield15 months ago

Interested to see all the debate about the UI for the Menus area.

Would please ask that we also consider accessibility in the discussion. There is an outstanding trac ticket #14045 (and duplicate #21289) about accessibility of the custom menu builder. Basically it is impossible or very difficult to be able to fully create a custom menu and amend the hierarchy if you can't use a mouse. The drag and drop functionality is an alien concept to blind users who will probably be using keyboard interaction with their screen readers.

Any solution to the Menus functionality should either be a) accessible for everyone, or b) an alternate accessible version should be provided alongside the drag/drop interface (as per Widgets).

Have heard mention on another ticket that there might be a rudimentary accessible non-js version in place already. Is that actually true, and could it form the basis for an accessible way forward?

comment:78 in reply to: ↑ 77 lessbloat15 months ago

Replying to grahamarmfield:

Interested to see all the debate about the UI for the Menus area.

Would please ask that we also consider accessibility in the discussion.

Hi Graham,

I agree. This is definitely on my list. I will do my best to address this in 3.6. :-)

comment:79 in reply to: ↑ 77 mmuro15 months ago

Replying to grahamarmfield:

Have heard mention on another ticket that there might be a rudimentary accessible non-js version in place already. Is that actually true, and could it form the basis for an accessible way forward?

With JavaScript turned off, there are up/down links that appear to change the order of each item.

comment:80 lessbloat15 months ago

A couple of minor CSS tweaks to the add new screen after you've deleted all of your menus in 23119.17.diff​.

lessbloat15 months ago

keoshi15 months ago

Title attribute outside metabox

comment:81 keoshi15 months ago

Hope I'm not too late to the party.

I Believe the double-tab separation between Management and Creation modes is really a nice and useful addition; should make all the difference for users to make the distinction naturally over time.

I only have one suggestion:

Add Menu

I feel like the menu name hasn't enough prominence where it is right now. I'd try to put it outside the box to make the information hierarchy clearer (outside defines how the menu is going to be defined; inside defines what belongs to this context).

http://cl.ly/image/1U1B2E2H3l41/content

I really like where this is headed!

comment:82 DrewAPicture15 months ago

  • Keywords 3.6-menus added

comment:83 lessbloat15 months ago

Results for user test 7 & 8 are in. We've made some great progress here.

comment:84 lessbloat15 months ago

Here are the items that I have left on my list:

  • Break this out into two files 1) manage 2) add/edit
  • Look into http://core.trac.wordpress.org/ticket/16075 (@DrewAPicture volunteered to look into this)
  • Look into potential of adding JS tree collapsing functionality to menu items
  • Look into way for theme devs to easily extend new "Common Links" meta box
  • Updated copy for help tabs (both manage, and add/edit screen) (@DrewAPicture will oversee this)
  • Updated copy for http://codex.wordpress.org/WordPress_Menu_User_Guide (@DrewAPicture will oversee this)
  • Updated copy for http://codex.wordpress.org/Appearance_Menus_Screen (@DrewAPicture will oversee this)
  • Accessibility (keyboard reordering) (I'll work on this one - @lessbloat)
  • Find someone to code review (and fix any of my hacky code) :-)
  • RTL testing
  • Browser compatibility testing
  • No JS testing

Did I miss anything? If you see something you'd like to tackle, please speak up. :-)

lessbloat15 months ago

comment:85 in reply to: ↑ 77 lessbloat15 months ago

Replying to grahamarmfield:

23119.18.diff​ is a start, adding "up" and "down" arrow keyboard accessibility. This allows you to reorganize items vertically within a menu. You just:

  • Tab to a menu item
  • press the up or down arrow key (the menu item will move up or down accordingly)
  • "Save your menu changes.

I'll try and work on "left" and "right" next week.

comment:86 follow-up: DrewAPicture15 months ago

From user test 7, I posted a comment about rewording the "menu updated" message links.

I also suggested adding a "Manage your widget menus" link to the theme location metabox.

Last point, it would be nice to list the theme location as a column in the list table even though we have the metabox adjacent to the list. It just seems like something that you'd expect to be listed.

Last edited 15 months ago by DrewAPicture (previous) (diff)

comment:87 in reply to: ↑ 86 ; follow-up: lessbloat15 months ago

Replying to DrewAPicture:

From user test 7, I posted a comment about rewording the "menu updated" message links.

I like it.

I also suggested adding a "Manage your widget menus" link to the theme location metabox.

Can you show us what you had in mind by mocking this up?

Last point, it would be nice to list the theme location as a column in the list table even though we have the metabox adjacent to the list. It just seems like something that you'd expect to be listed.

Good idea. I agree.

DrewAPicture15 months ago

Copy change on updated msg + numbered specifiers

comment:88 DrewAPicture15 months ago

23119.18.1.diff modifies the updated message link text and adds numbered specifiers for the sprintf.

http://f.cl.ly/items/100I2t0w2G360K180V22/Screen%20Shot%202013-01-11%20at%201.43.22%20PM.png

comment:89 follow-up: DrewAPicture15 months ago

Is "Use this menu within your theme" locked in for the metabox? If so, I'd almost be tempted to change "Assign a theme location for this menu" to mimic that. As I mentioned on Skype, it might also be worth it to swap out the anchor text based on whether the menu already has an assignment -- something I'll play with.

comment:90 in reply to: ↑ 87 ; follow-up: DrewAPicture15 months ago

Replying to lessbloat:

Replying to DrewAPicture:

I also suggested adding a "Manage your widget menus" link to the theme location metabox.

Can you show us what you had in mind by mocking this up?

I was thinking something along these lines:

http://f.cl.ly/items/2N0T0a3D461K0t2Q2a04/widget_menus.png

comment:91 in reply to: ↑ 89 ; follow-up: lessbloat15 months ago

Replying to DrewAPicture:

Is "Use this menu within your theme" locked in for the metabox?

Nope. What did you have in mind?

comment:92 in reply to: ↑ 90 ; follow-up: lessbloat15 months ago

Replying to DrewAPicture:

I was thinking something along these lines:

http://f.cl.ly/items/2N0T0a3D461K0t2Q2a04/widget_menus.png

Linking to widgets is something I've not fully worked out yet. I like that we're exposing the fact that you can use menus in widgets. My only worry is what happens when the user clicks the link? There is a lot on that page, and I think it will be hard for most new users to make the connection that they then need to 1) add a "custom menu" widget to their sidebar, and then 2) select a menu within that widget and save it. Wondering if there is anything else we can do there to bring more clarity to this process.

comment:93 in reply to: ↑ 91 DrewAPicture15 months ago

Replying to lessbloat:

Replying to DrewAPicture:

Is "Use this menu within your theme" locked in for the metabox?

Nope. What did you have in mind?

I like it, probably better than the 'Assign a theme location for this menu' anchor on the update message. Consistency in messaging is better because people read it, click the link, repeat it and look for something that matches. And if it matches exactly, all the better.

comment:94 in reply to: ↑ 92 JerrySarcastic15 months ago

Replying to lessbloat:

Linking to widgets is something I've not fully worked out yet. I like that we're exposing the fact that you can use menus in widgets. My only worry is what happens when the user clicks the link? There is a lot on that page, and I think it will be hard for most new users to make the connection that they then need to 1) add a "custom menu" widget to their sidebar, and then 2) select a menu within that widget and save it. Wondering if there is anything else we can do there to bring more clarity to this process.

For sure the last thing we want to do is dump a user on the Widgets page to connect the dots for themselves. How about just some hint text, like:

"You can also use the Custom Menu Widget to add menus to the sidebar of your site. Manage my widgets."

That's a bit wordy, but at least points the user in the right direction...

lessbloat15 months ago

comment:95 in reply to: ↑ 77 ; follow-up: lessbloat15 months ago

Replying to grahamarmfield:

23119.19.diff adds full keyboard accessibility for re-arranging menu items.

Testing
1) Focus on a menu item (there has to be more than one)
2) pressing the right, left, up or down key.

Supports RTL. Supports moving single item as well as items with children (sub items). Ideally, it should behave identical to drag/drop. With that said, there is a lot going on here, so please ping me if you notice any issues.

Patch also adds class-wp-menus-list-table.php back in (was missing in 23119.18.1.diff​)

comment:96 in reply to: ↑ 71 ; follow-ups: lessbloat15 months ago

Replying to jkudish:

@lessbloat: some thoughts on 23119.14.diff:

What other links do you imagine under "Common Links"? Do you expect this to auto-populate with actual frequently-used links as users add items to their menus? Or is it just meant to be a specially-curated list of links?


My thought was to show "Home" and "login" by default. Mostly because these are particularly hard to figure out how to add to the menu. But then to allow theme devs to hook in and add/remove whatever links they want. I don't think we should auto-populate with frequently-used links.

If the latter, then I suggest that we rename it to something different, as "common" suggests to me that they would be links I've inserted before.

Open to suggestions. How about "Helpful links", or "Quick links"?

Also, wonder if anyone has extra suggestions as for links to add in there? Seems silly to have that meta box for just 2 links.

I think it's okay to have just 2 links. I don't want to add too many, or we'll lose the "Custom Links" meta box at the bottom fold.

comment:97 valeriyan15 months ago

  • Cc k.valerie@… added

comment:98 in reply to: ↑ 96 toscho15 months ago

Replying to lessbloat:

Replying to jkudish:

Also, wonder if anyone has extra suggestions as for links to add in there? Seems silly to have that meta box for just 2 links.

I think it's okay to have just 2 links. I don't want to add too many, or we'll lose the "Custom Links" meta box at the bottom fold.

How about the latest post from all post types available in nav menus?

So when I have written a new page I can head over to menu admin and will find that page immediately.

DrewAPicture15 months ago

+ common links filter

comment:99 in reply to: ↑ 96 ; follow-up: DrewAPicture15 months ago

23119.20.diff adds a filter for the $common_links array, also swaps out get_site_url() for get_home_url() on the default 'Home' link.

Just a note about "Home" links. As long as we keep "common links" as the type "custom" (vs page, post, CPT, taxonomy, etc.), there's code already in place to make sure the home links can be recognized as the "current" page. See wping/nav-menu-template.php for more on that.

Replying to lessbloat:

Replying to jkudish:

If the latter, then I suggest that we rename it to something different, as "common" suggests to me that they would be links I've inserted before.

Open to suggestions. How about "Helpful links", or "Quick links"?

What about "Useful Links"?

comment:100 in reply to: ↑ 99 jkudish15 months ago

Replying to DrewAPicture:

Replying to lessbloat:

Replying to jkudish:

If the latter, then I suggest that we rename it to something different, as "common" suggests to me that they would be links I've inserted before.

Open to suggestions. How about "Helpful links", or "Quick links"?

What about "Useful Links"?

I like "Useful Links" and "Quick Links" the most out of all the suggestions so far.

comment:101 follow-up: travisnorthcutt15 months ago

Is it necessarily good to have a common links/useful links/quick links/etc. box? I'm not necessarily opposed, but I think it's worth examining before adding that.

comment:102 in reply to: ↑ 101 ; follow-up: DrewAPicture15 months ago

Replying to travisnorthcutt:

Is it necessarily good to have a common links/useful links/quick links/etc. box? I'm not necessarily opposed, but I think it's worth examining before adding that.

I think it's a nice-to-have, and could be a nice way of tying up some loose ends:

  • Moving the 'Home' link out of the Pages metabox #14325
  • Make it easy to add a link to the login form (which many users have trouble with) comment:96
  • Provide a filter for plugins to specify additional useful links via a filter comment:99

I especially see the benefit for plugins that may have specialty feeds or pages to link to. As it stands, if you want anything custom, you have to type it out yourself.

comment:103 adamsilverstein15 months ago

  • Cc ADAMSILVERSTEIN@… added

comment:104 Marco_Teethgrinder15 months ago

  • Cc marco@… added

comment:105 saltcod15 months ago

  • Cc saltcod@… added

comment:106 lessbloat15 months ago

  • Summary changed from UI Improvements to nav-menus.php to UX Improvements to nav-menus.php

comment:107 lessbloat15 months ago

From IRC:

lessbloat - jkudish: Do you think we could do away with bulk actions on the menus list screen? I just think it will be pretty edge case that someone has enough menus to need them, and if we got rid of them, the list table would align with the "Menus within your theme" meta box.
jkudish - yes can do. can you add that to the ticket so I remember?

And hopefully, it will likely make that screen slightly less heavy.

Here's what it will look like:

http://f.cl.ly/items/2T2S1K1x3N3D3b2C363O/menus-list.jpg

Last edited 15 months ago by lessbloat (previous) (diff)

comment:108 follow-ups: alex-ye15 months ago

  • Cc nashwan.doaqan@… added

I have not testing the new patches until now , but I want to talk about some difficulties I founded in the previous WordPress versions ..

1 - It's hard to move\delete more than one menu element in the same time .

2 - When Adding a page with it's child pages the users expect that the child pages be a child elements in the menu too ! .

comment:109 in reply to: ↑ 102 alex-ye15 months ago

Replying to DrewAPicture:

I especially see the benefit for plugins that may have specialty feeds or pages to link to. As it stands, if you want anything custom, you have to type it out yourself.

Yes , I agree with you I was thinking about something like that before a few months , It's very good to plugins and themes to give the user more powerful menus .

Another Idea is to add a context menu items , I means add the ability to show items for the logged-in-users or shows items in home page only ... etc ... I think it's a plugin job but it still a good idea :)

Last edited 15 months ago by alex-ye (previous) (diff)

comment:110 ramiy15 months ago

  • Cc r_a_m_i@… added

comment:111 in reply to: ↑ 108 ; follow-up: lachlanj15 months ago

Replying to alex-ye:

2 - When Adding a page with it's child pages the users expect that the child pages be a child elements in the menu too ! .

I couldn't agree more with this. The ability to automatically add child pages (preferably with a checkbox that can be turned on or off depending on preference) would be a great improvement to menus.

Even though Menu's are separate from the actual page structure, in my experience many novice users assume that child pages will get added with the top level page automatically.

The best case senario would be to have all subpages physically added (when the option is checked) so that individual subpages can be removed if necessary.

comment:112 in reply to: ↑ 108 ; follow-up: SergeyBiryukov15 months ago

Replying to alex-ye:

2 - When Adding a page with it's child pages the users expect that the child pages be a child elements in the menu too ! .

FWIW, there's a plugin for that:
http://wordpress.org/extend/plugins/add-descendants-as-submenu-items/

comment:113 in reply to: ↑ 111 travisnorthcutt15 months ago

Replying to lachlanj:

I couldn't agree more with this. The ability to automatically add child pages (preferably with a checkbox that can be turned on or off depending on preference) would be a great improvement to menus.

Even though Menu's are separate from the actual page structure, in my experience many novice users assume that child pages will get added with the top level page automatically.

The best case senario would be to have all subpages physically added (when the option is checked) so that individual subpages can be removed if necessary.

I see how you could make a case for this, but to be fair, when you add pages to a custom menu, what you see is then an accurate representation of what the menu will be after saving, so it's not as if any behavior is hidden from the user.

Furthermore, the default behavior (which I just tested in 3.5 with the Twenty Eleven theme active), with no custom menus created, is to add all pages to the menu, including child pages, as sub-menu items under their parent pages. Because of this behavior (which is good, imo), adding a checkbox to the custom menu creation area titled something like "Add all child pages automatically" would be rather ambiguous, as it could have five meanings that I can think of right now, depending on where it was placed:

  1. Only add currently extant pages which have the page I'm actively adding as their parent. If new child pages are created later, do not add them automatically.
  1. Regardless of when they come into existence, add all child pages of the page I'm actively adding to this menu. If I add a new child page next week, add it to the menu.
  1. Do # 1, but for all parent pages currently in the menu.
  1. Do # 2, but for all parent pages currently in the menu.
  1. Do # 1, but for all parent pages, regardless of when they are added to the menu.
  1. Do # 2, but for all parent pages, regardless of when they are added to the menu.

I should note that this list went from two scenarios to six scenarios as I was typing it. Suffice it to say, I think adding such a checkbox has the potential to introduce a lot of confusion and complexity! However, like I said, I could see a case (whether I agree with it or not) for it, so perhaps it would be worth creating a ticket to discuss.

comment:114 in reply to: ↑ 108 ; follow-up: lessbloat15 months ago

Replying to alex-ye:

1 - It's hard to move\delete more than one menu element in the same time

Any thoughts on how we might remedy this?

2 - When Adding a page with it's child pages the users expect that the child pages be a child elements in the menu too ! .

My vote would be to keep this as a plugin (comment:112).

Last edited 15 months ago by SergeyBiryukov (previous) (diff)

comment:115 kwight15 months ago

  • Cc kwight@… added

comment:116 follow-ups: lessbloat15 months ago

I've been thinking about the proposed new layout over the weekend, and the one thing that still bugs me is the "Menus within your theme" meta box. It still seems out of place. I mocked up an alternative approach, and wanted to get your take:

What if we removed the "Menus within your theme" meta box from the manage screen.

http://f.cl.ly/items/011y1g3h093B14440j1d/manage.jpg

And put it at the top of "Screen Options":

http://f.cl.ly/items/2D0L131B1N1Q3e3f3f1t/screen-options.jpg

Then the "default menu for your theme" link in the "Save Menu" success message would simply slide down "Screen Options" when clicked.

We of course would user test this approach to find out if it actually works for users.

Thoughts?

Last edited 15 months ago by lessbloat (previous) (diff)

comment:117 in reply to: ↑ 116 mmuro15 months ago

Replying to lessbloat:

I've been thinking about the proposed new layout over the weekend, and the one thing that still bugs me is the "Menus within your theme" meta box. It still seems out of place. I mocked up an alternative approach, and wanted to get your take:

What if we removed the "Menus within your theme" meta box from the manage screen.

http://f.cl.ly/items/011y1g3h093B14440j1d/manage.jpg

And put it at the top of "Screen Options":

http://f.cl.ly/items/2D0L131B1N1Q3e3f3f1t/screen-options.jpg

Then the "default menu for your theme" link in the "Save Menu" success message would simply slide down "Screen Options" when clicked.

We of course would user test this approach to find out if it actually works for users.

Thoughts?

The problem with this approach is that you are hiding primary functionality within the Screen Options tab, which should be used to show/hide items in the admin screen.

If you want to get rid of that meta box, you might as well get rid of the two tabs and use the header "Add New" method and just display it on the menu screen in the same spot it's always been.

comment:118 in reply to: ↑ 116 ; follow-up: ramiy15 months ago

Replying to lessbloat:

What if we removed the "Menus within your theme" meta box from the manage screen.

http://f.cl.ly/items/011y1g3h093B14440j1d/manage.jpg


I prefer this approach. The "Menus within your theme" should be controlled from the "Theme Customizer".

comment:119 in reply to: ↑ 118 ; follow-up: lessbloat15 months ago

Replying to mmuro:

The problem with this approach is that you are hiding primary functionality within the Screen Options tab, which should be used to show/hide items in the admin screen.

This is true...

Well scratch that idea. ;-)

Replying to ramiy:

I prefer this approach. The "Menus within your theme" should be controlled from the "Theme Customizer".

I don't think that all themes have a "Theme Customizer" page, so I'm not sure that will work either. Plus this seems like it would be just as hard to discover.

comment:120 follow-up: travisnorthcutt15 months ago

@lessbloat sounds like you've already decided this way, but +1 on not hiding the "menus in your theme" functionality like that.

comment:121 in reply to: ↑ 120 lessbloat15 months ago

Replying to travisnorthcutt:

@lessbloat sounds like you've already decided this way, but +1 on not hiding the "menus in your theme" functionality like that.

Yep, but they still bug me as is... :-)

comment:122 husobj15 months ago

+1 to not hiding in another area of appearance.
They should be managed somehow within the Menus section I think.

Another tab for "Theme Menus" perhaps?
Not sure about that, just throwing out another suggestion.

comment:123 in reply to: ↑ 114 alex-ye15 months ago

Replying to lessbloat:

Any thoughts on how we might remedy this?

mmm , I am not sure about the best way to achieve this but I have an idea on how can we do it , Simply adding a check-box beside the menu item title , so by checking more than one item makes easy to move or delete ... etc

http://store2.up-00.com/Nov12/vrg87739.jpg

The image source from comment:81 :)

comment:124 in reply to: ↑ 112 ; follow-up: alex-ye15 months ago

Replying to SergeyBiryukov:

FWIW, there's a plugin for that:
http://wordpress.org/extend/plugins/add-descendants-as-submenu-items/

BOF , You know that many of WordPress core features comes from plugins or themes , Maybe it's not worth to you but it worth a lot for many users out there :)

comment:125 follow-up: DrewAPicture15 months ago

I also took some time over the weekend to sort of hone in on what exactly the problem is that we're solving. Having not watched the initial tests, I came to the conclusion that we're really trying to relieve two main pain points:

  • Managing multiple menus in an easily discoverable way
  • Cramming the workflow into a single screen

At the devchat last week, @nacin made a pretty valid point that the proposed two-tab workflow feels "heavy". I think that if we step back a little bit at look at both the pain points we're trying to address and the ideas we've come up with thus far, we can take it from a new, educated approach.

If you look at, for instance, the way @lessbloat was able to direct the focus on the "New Menu" screen by using an overlay to disable anything but the new menu creation form, that's something that works really well to promote visual hierarchy.

What if we do something like this:

Menus overall workflow:

  • Return to the original idea of a single-screen menus workflow

Menu location metabox & multiple menu management:

  • Move the idea of assigning a menu to a location into the menu editor itself, therefore tying it more to the workflow of, "I'm editing this menu, I want it to be used in 'this place'"
  • Drop using the tabbed navigation system for switching between menus. In my experience, users seem confused by this most of the time.
  • Leverage the "location" metabox/area to instead act as the primary launchpad for toggling between menus and use the overlay effect to highlight this area when you first hit the page.

I can do a mockup of this once I get to the airport but that's the gist of it. It's the equivalent of a UI refresh but not a complete overhaul.

comment:126 alex-ye15 months ago

Replying to travisnorthcutt:

adding a checkbox to the custom menu creation area titled something like "Add all child pages automatically" would be rather ambiguous .

I agree with you , What about adding a checkbox in the Page Meta Box ( or any post-type that supports Hierarchical ) shows when selecting a parent item ( Item that have a child items ) titled by something like 'Hierarchical ?' ...

comment:127 in reply to: ↑ 124 lessbloat15 months ago

Replying to alex-ye:

adding a check-box beside the menu item title , so by checking more than one item makes easy to move or delete ... etc

I worry about this for 2 reasons:

1) It will add complexity to an already cluttered UI
2) I'm not convinced that 80% of users will find this essential functionality.

For these reasons, I'd vote to keep "batch menu item actions" as a great idea for a plugin, but not a perfect fit for core.

Replying to alex-ye:

BOF , You know that many of WordPress core features comes from plugins or themes , Maybe it's not worth to you but it worth a lot for many users out there :)

I also feel like this is a great idea for a plugin, but overkill for core.

In the end, my goal is to have menus be clean, lean, and mean for the majority of users. But that doesn't mean that they can't be extended (through plugins) for additional use cases.

Last edited 15 months ago by lessbloat (previous) (diff)

comment:128 in reply to: ↑ 125 lessbloat15 months ago

Replying to DrewAPicture:

At the devchat last week, @nacin made a pretty valid point that the proposed two-tab workflow feels "heavy".

I'm not particularly attached to the idea of having a manage screen and an add/edit screen. With that said, I do expect any concept we consider to test as well, if not better than the 2 tab approach.

The only measure of effectiveness that I have to fall back on is that the two tab approach seemed to test well (especially since the users were only working with 1 or 2 menus). Neither of them seemed confused, or overwhelmed by the manage screen.

What if we do something like this:

Menus overall workflow:

  • Return to the original idea of a single-screen menus workflow

Menu location metabox & multiple menu management:

  • Move the idea of assigning a menu to a location into the menu editor itself, therefore tying it more to the workflow of, "I'm editing this menu, I want it to be used in 'this place'"
  • Drop using the tabbed navigation system for switching between menus. In my experience, users seem confused by this most of the time.
  • Leverage the "location" metabox/area to instead act as the primary launchpad for toggling between menus and use the overlay effect to highlight this area when you first hit the page.

I'm happy to test anything we think might perform better. But my gut says that any single screen that attempts to:

1) manage menus
2) add menus,
3) edit menus, and
4) manage theme locations

is going to end up being somewhat complex. But again, please mock something up, I'd be happy to test it.

comment:129 lessbloat15 months ago

As a heads up I just ran one more user through to test the 2 tab concept. I was looking to test an idea I had about visually highlighting the “Menus in your theme” meta box when a user clicks there from the “add/edit” screen success message. It doesn't appear to have helped in that regard, but using the two tabs still seems to offer a fairly simple flow overall.

comment:130 jkudish15 months ago

I was travelling so I am just catching up on the conversation here and going to quickly throw in my thoughts on everything that's been said (but will bare repeating at the Menus discussion in a few minutes as well. Essentially I agree with @lessbloat on most of his points, but will elaborate:

  • I agree in regards to complex functionality, that should stay in plugins and we should keep the UI minimal and clean while affording functionality for ~80% of users
  • I am also not married to the two tab UI, but just as the test confirm, it's a much better interface than what we had before. If someone makes a good mockup that shows a redo of the one tabbed UI, I might jump ship :)
  • The "locations" meta box was a bit odd on the right side. But it also most definitely does not belong hidden in "screen options", that's a really bad place for it. I think that either below or above the list of menus may be a better place for it. It's hard to only display it when editing a specific menu since it's the kind of thing that could be changed without needing edit a menu.

Just my 2 cents. Looking forward to the discussion shortly.

comment:131 lessbloat15 months ago

I thought I'd post a couple screenshots of where we're at currently with 23119.20.diff. Here's the manage screen:

http://f.cl.ly/items/102S1h1d1M2s2i0G0o2z/manage-screen.jpg

Here's the edit screen:

http://f.cl.ly/items/1C1S3K2Y2k0g3F1q3P2s/edit-screen.jpg

And the add new screen:

http://f.cl.ly/items/1v2L1h340L0O26453n0s/add-new-screen.jpg

comment:132 mmuro15 months ago

Perhaps the menu name/save area has room to grow. This might be a good spot for assigning them to a theme and a little slide toggle could be used. I use this exact method in one of my plugins to allow for lots of different options that wouldn't otherwise fit.

comment:133 in reply to: ↑ 119 ; follow-up: ramiy15 months ago

Guys, let's examine again the "Theme Customizer" (or "Live Preview") approach - to change the theme design workflow.


The new worklfow i propose:

  • Manage menus/sidebars - both Menus UI and Widgets UI will use WP_List_Table to add/edit/delete custom menus and sidebars.
  • Manage theme locations - to assign specific menu to a theme-location (or widget-set to theme-sidebar) we will do it throw the theme live preview.

Which means - remove the "Menus within your theme" meta box from the Menus screen.


Disadvantages:

  • Two step workflow.
  • New approach, hard to adopt.

Advantages:

  • Increase "Live Preview" usage.
  • Same workflow for menus and widgets.
  • All the design changes will be controlled from one place ("Live Preview"), and the user will see how the changes effect his site.

comment:134 in reply to: ↑ 133 ; follow-up: jkudish15 months ago

Replying to ramiy:

Guys, let's examine again the "Theme Customizer" (or "Live Preview") approach - to change the theme design workflow.

In theory this is a good place for picking the in-theme menu locations, and one we should accommodate/allow for. However since most or at least not all themes support the theme customizer, and we need to remain backwards compatible, we can't have this as the only way to set theme menu locations.

comment:135 in reply to: ↑ 134 ; follow-up: ramiy15 months ago

Replying to jkudish:

Since most or at least not all themes support the theme customizer, and we need to remain backwards compatible, we can't have this as the only way to set theme menu locations.

We have backwards compatibility.

The "Theme Customizer‬is" was added to WordPress in 3.4, it's not a Theme-Feature that need activation, it's an admin screen.

Last edited 15 months ago by ramiy (previous) (diff)

comment:136 in reply to: ↑ 135 jkudish15 months ago

Replying to ramiy:

it's not a Theme-Feature that need activation, it's an admin screen.

For some reason I thought that a theme needed to add theme support for the customizer. I tested it out and you're right. My mistake :)
I noticed that menu theme locations are already available in the customizer though...

comment:137 follow-ups: rmccue15 months ago

Keep in mind: themes aren't the only place menus can be used, so we need to be careful that we don't force a workflow that assumes they're only used in themes. I believe lachlanj has input on that and also some use cases to give a better sense of how menus are actually used in the wild/production.

comment:138 in reply to: ↑ 137 ramiy15 months ago

Replying to rmccue:

Keep in mind: themes aren't the only place menus can be used, so we need to be careful that we don't force a workflow that assumes they're only used in themes. I believe lachlanj has input on that and also some use cases to give a better sense of how menus are actually used in the wild/production.

I know that menus also used in widgets, it doesn't break anything. We just change the UI and present a new User Experience for changing theme design.

comment:139 toscho15 months ago

It is possible to use a menu in wp-login.php only, activated per plugin. The widget manager or the theme customizer don’t help in these cases.

comment:140 in reply to: ↑ 137 lachlanj15 months ago

Replying to rmccue:

Keep in mind: themes aren't the only place menus can be used, so we need to be careful that we don't force a workflow that assumes they're only used in themes. I believe lachlanj has input on that and also some use cases to give a better sense of how menus are actually used in the wild/production.

Thanks rmccue, I thought it might be helpful to show 2 different 'real world' cases for how we have used menus on client sites.

  1. http://cl.ly/image/3i2v3C3H0I2v - This theme has 3 menus locations, while 2 other menus (Download Sidebar and Video Sidebar) are used in widget areas.
  1. http://cl.ly/image/0l3p2j1F3p2y - This theme uses 7 menus locations in total, 3 standard menus but the theme also has 5 different landing pages for each department in the company, and each of these has it's own unique menu.

This is similar to what has been discussed above, but I thought some screenshots might help

comment:141 follow-up: ramiy15 months ago

This is what i was thinking:

When themes register menus and sidebars,

// Register Navigation Menus
function custom_navigation_menus() {
	$locations = array(
		'primary_menu' => __( 'Primary Menu', 'text_domain' ),
	);
	register_nav_menus( $locations );
}
add_action( 'init', 'custom_navigation_menus' );


// Register Sidebar
function custom_sidebar()  {
	$args = array(
		'id'            => 'unique_id',
		'name'          => __( 'Sidebars', 'text_domain' ),
		'description'   => __( 'Sidebar Description', 'text_domain' ),
		'class'         => '',
		'before_title'  => '<h2 class=\"widgettitle\">',
		'after_title'   => '</h2>',
		'before_widget' => '<li id=\"%1$s\" class=\"widget %2$s\">',
		'after_widget'  => '</li>',
	);
	register_sidebar( $args );
}
add_action( 'widgets_init', 'custom_sidebar' );


// Code generated using GenerateWP.com

We will see both Menus and Sidebars on the "Theme Customizer".

http://i.imgur.com/t9GOjrM.jpg

The Menu screen and the Widget screen will be used to manage links & wigets.

Menus admin screen:
http://i.imgur.com/WAeJMjK.jpg

Sidebars admin screen:
http://i.imgur.com/reMYoku.jpg

The "Customizer" will be used to assign specific menu/sidebar to the theme.

This is basicly the Two step workflow.

comment:142 in reply to: ↑ 141 ; follow-up: lessbloat15 months ago

Replying to ramiy:

This is what i was thinking:
The "Customizer" will be used to assign specific menu/sidebar to the theme.

Please note, we are only focusing on menus improvements for this ticket (but I hope to see improvements to widgets in a future release as well).

Assigning the theme location inside the customizer is definitely worth testing (especially since it's already coded up). It would eliminate the meta box from the manage screen, and give the user a visual representation of the change (and how it affects their theme). If we continue to support IE7 in 3.6, we'd have to come up with a work around, since the customizer doesn't work (that I recall) in IE7.

comment:143 in reply to: ↑ 142 ramiy15 months ago

Replying to lessbloat:

If we continue to support IE7 in 3.6, we'd have to come up with a work around, since the customizer doesn't work (that I recall) in IE7.

WordPress 3.2 drop IE6 support and Start End-of-life (EOL) cycle for IE7. Are you sure you want to add customizer support for IE7?

comment:144 helen15 months ago

Nobody is saying anything about supporting the customizer in IE7. Let's stay on topic, please. This ticket is already quite long.

comment:145 desrosj15 months ago

  • Cc desrosj@… added

comment:146 follow-up: matveb15 months ago

Amazing progress on making Menus more usable. Have you considered something like this for the "manage screen"?

http://f.cl.ly/items/0N2n3l0k272L1s2u3j27/menu-areas.png

Allow people to drag their created menus into the theme's menu locations, instead of using dropdowns on its own panel. (We could also eventually include registered sidebars there, and automatically create a "custom menu widget" when you drag a menu to them.)

comment:147 in reply to: ↑ 146 travisnorthcutt15 months ago

Replying to matveb:

Amazing progress on making Menus more usable. Have you considered something like this for the "manage screen"?

Allow people to drag their created menus into the theme's menu locations, instead of using dropdowns on its own panel. (We could also eventually include registered sidebars there, and automatically create a "custom menu widget" when you drag a menu to them.)

A drag and drop interface was discussed on IRC, and dismissed as too clumsy and not terribly accessible, much like the current widgets interface.

comment:148 follow-up: iamronen15 months ago

I apologize if the timing is off (too late?) but I believe there is another important UI shortcoming that I have not seen mentioned (in browsing this ticket).

The part of the screen that holds the UI containers from which menu content items can be selected is dysfunctional when there are many items (pages/posts/categories) to choose from ... especially when there are additional custom post-types and they too are populated with much content.

I wrote about this with what may be a direction to explore to make it better:
http://www.odharma.com/2010/07/review-of-wordpress-menus-user-interface/

comment:149 in reply to: ↑ 148 ; follow-up: lessbloat15 months ago

Replying to iamronen:

I wrote about this with what may be a direction to explore to make it better:
http://www.odharma.com/2010/07/review-of-wordpress-menus-user-interface/

Hey, thanks for chiming in. It's never too late (until we hit code freeze ;-)). I actually played around with a similar concept a while back: http://davemart.in/?p=74.

The big drawback to this approach that I saw (aside from it being a drastically different flow from what users are used to - and as a result something they would have to likely re-teach themselves), is that you lose the ability to add multiple pages, categories, or posts at once. In the current flow, you can select a bunch of pages, and add them all at once. With the flow you propose, you'd have to add each page one by one. I feel like that is a blocker for going this route.

comment:150 in reply to: ↑ 149 ; follow-up: iamronen15 months ago

Replying to lessbloat:

The big drawback to this approach that I saw (aside from it being a drastically different flow from what users are used to - and as a result something they would have to likely re-teach themselves), is that you lose the ability to add multiple pages, categories, or posts at once. In the current flow, you can select a bunch of pages, and add them all at once. With the flow you propose, you'd have to add each page one by one. I feel like that is a blocker for going this route.

  1. My main point is that the second largest (if not largest) UI real-estate area should go to the "things I can add to the menu".
  2. The tabbed area makes it possible to allocate more real-estate to each of the "types of things" that can be added to the menu. I see no need to have on screen at the same multiple sources. If I am looking for posts - then let me see just posts. When I want to select from pages or categories or anything else I don't need to scroll down to look for them ... and to lose sight (literally) of the menu I am working on.
  3. Within the tabbed area there is then plenty of space that can be used for better search and filtering.
  4. Because the spaces are tabbed it may be possible to do on demand loading of data (instead of loading everything, everytime the screen loads). That may drastically improve page performance ...
  5. AND you can use that improved performance to do a smarter load ... like indicating somehow which items have already been added to the menu.
  6. You can still add checkboxes for selecting multiple items and an "add to menu" button. However what I tried to suggest was one click add instead of two click add. Instead of clicking to select each menu and then having to move the moust somewhere else AND clicking one more time "add to menu" you simply add directly. It feels to me like a faster, smoother and more efficient experience (unless I am missing something).

comment:151 in reply to: ↑ 150 ; follow-ups: lessbloat15 months ago

Replying to iamronen:

It feels to me like a faster, smoother and more efficient experience (unless I am missing something).

Let's try and keep this thread on task please. I do appreciate your input. But, the mockup you presented has a number of shortcomings, the largest of which I already mentioned (it being a drastically different flow from what users are used to). Which no amount of reasoning can remedy.

comment:152 follow-up: lessbloat15 months ago

I mocked up my interpretation of Nacins concept here. I'd love to hear your thoughts, but let's keep feedback for that design over on that thread for now.

comment:153 in reply to: ↑ 151 ramiy15 months ago

Replying to lessbloat:

I do appreciate your input. But, the mockup you presented has a number of shortcomings, the largest of which I already mentioned (it being a drastically different flow from what users are used to). Which no amount of reasoning can remedy.

@lessbloat, why not change the current flow? WordPress 3.5 changed drastically the media manager and the wordpress community embrace those changes. People love changes.

comment:154 in reply to: ↑ 152 iamronen15 months ago

Replying to lessbloat:

I mocked up my interpretation of Nacins concept here. I'd love to hear your thoughts, but let's keep feedback for that design over on that thread for now.

That mockup still does not address the most important area of the screen - the things I can pull into the menu. Try to populate the mockup with real content (put in a list of pages/posts/categories/custom post types ... and see that you simply can't.

comment:155 in reply to: ↑ 151 ; follow-up: iamronen15 months ago

Replying to lessbloat:

Replying to iamronen:

It feels to me like a faster, smoother and more efficient experience (unless I am missing something).

Let's try and keep this thread on task please. I do appreciate your input. But, the mockup you presented has a number of shortcomings, the largest of which I already mentioned (it being a drastically different flow from what users are used to). Which no amount of reasoning can remedy.

This is off-topic (but I will not pursue it further then this short comment), but I think it is important. Is there a way/place/opportunity in the WordPress development process to debate your position? I'm OK with you asking me to back off ... really ... but is that the best thing for a design effort?

comment:156 in reply to: ↑ 155 ; follow-up: DrewAPicture15 months ago

Replying to iamronen:

This is off-topic (but I will not pursue it further then this short comment), but I think it is important. Is there a way/place/opportunity in the WordPress development process to debate your position? I'm OK with you asking me to back off ... really ... but is that the best thing for a design effort?

It's funny you should ask. Earlier today, @lessbloat proposed three approaches for this nav-menus action on the make.wordpress.org/core P2 site. Your two cents on that post are welcomed and encouraged.

Once the scope has been decided, we'll nail down the UI/workflow and work on revising our documentation. You can find and comment on @lessbloat's post here: http://make.wordpress.org/core/2013/01/23/for-tomorrows-menu-office-hours-i-only/#more-2813

comment:157 in reply to: ↑ 156 ; follow-up: ramiy15 months ago

Replying to DrewAPicture:

Earlier today, @lessbloat proposed three approaches for this nav-menus action on the make.wordpress.org/core P2 site. Your two cents on that post are welcomed and encouraged.

Seems like the core P2 does not post my comments, so i will write my response here.

The current menu screen has too many functions (add new menus, edit existing menus, manage manus, assign menus to theme locations). Its all mixed up in one screen. Very confusing. This is why i prefer the two screens approach.

Not to mention that the "two screens approach" very similar to the post/page UI, which makes it much easier to use.

comment:158 in reply to: ↑ 157 helen15 months ago

Replying to ramiy:

Seems like the core P2 does not post my comments, so i will write my response here.

I don't see any comments from you awaiting moderation and other people are commenting just fine. Can you try to figure out what's going wrong there? This ticket is getting extremely long and difficult to follow, and it would be sad to lose your comment and its context.

comment:159 lessbloat15 months ago

Replying to iamronen:

Is there a way/place/opportunity in the WordPress development process to debate your position?

Absolutely. For clarity's sake:

  • I'm really not trying to be a jerk. (honest!) :-)
  • This ticket is not the best place to post drastically new ideas.
  • Even though I'm the lead for this feature, I don't have final say on any of it (that is left to Mark and Aaron). My role is to assist in the development, but also to keep the development of this feature on track, and on time.

We've got office hours for this feature each Mon & Thu at 21:00 UTC (4:00pm EST, 1:00pm PST) in #wordpress-dev. After we've covered any agenda items, you are free to bring up whatever ideas & concerns that you may have. There is also the make/core P2. You are welcome to leave whatever comments there that you'd like (as long as they are on topic). Those are your two best options, if you'd like to present a new idea.

comment:160 lessbloat15 months ago

Some updated concepts posted here: http://make.wordpress.org/core/2013/01/23/for-tomorrows-menu-office-hours-i-only/#comment-7777 based on our discussion Thursday.

Please leave feedback on that thread. Thanks! :-)

comment:161 lessbloat15 months ago

Here's my latest mockup proposal.

jkudish will gather some more data for tomorrows meeting (held this Thursday @ 21:00UTC in #wordpress-dev). We need finalize the direction we're taking with menus if this is going to make 3.6 - I hope to see you there.

comment:162 ramiy15 months ago

Still have js problems on P2 so here is what i think on the latest mockups:

The general direction is very good, selective menu screens depending on menu count is a very nice approach.

The new menu screen mockup is still overwhelming with management + editing + theme location assignment all in the same page. I personally prefer the two step workflow.

But if this is the preferred way, have you considered 3 columns menu screen?

http://i.imgur.com/4zDpdQt.png

We can add a screen option to hide the third column.

Last edited 15 months ago by ramiy (previous) (diff)

lessbloat15 months ago

comment:163 lessbloat15 months ago

23119.21.diff gets us back on track with:

Zero Menus State

When users have 1 theme location, and zero menus, and at least one page, we show them a simplified blank slate screen. We pre-populate it with the menu items that show up on their site by default (when no menus have been added).

http://f.cl.ly/items/3O2Q2G2v2q1m2x1z0U0A/zero-state.jpg

Single Menu State

When users have one menu, we take them right to editing it (they don't see the menu management drop down):

http://f.cl.ly/items/1e3C04193q2O3k2V2G3i/single-state.jpg

Add Menu State

We reduced the amount of copy, and improved the visual hierarchy:

http://f.cl.ly/items/3s1J251z0V1k0u2m120q/add-state.jpg

Multiple Menus State

When a user has more than one menu, we show them a drop down at the top where they can select another menu. This replaces the tabs approach which was confusing for users on multiple fronts:

http://f.cl.ly/items/3V0a1z0j1O1l1F2k1z0N/manage-state.jpg

Menu items

  • We added keyboard accessibility for moving menu items
  • We added "sub item" as helper text when menu items are dragged to a sub item position (multiple users had a positive reaction to this, as it improves clarity as to what just happened if they drag a menu item to a sub position by mistake).

Custom Links

Changed "Label" to "Link Text" (Before this change some users were not adding link text - since the change, everyone has).

Additional Improvements

  • Improved & shortened copy in a bunch of places to provide better at-a-glance clarity
  • Since the admin messages never fade away, some users were experiencing trouble knowing if their menus were saved (when they saved their menu multiple times in a row). We added in a slide down effect, which appears to have fixed the issue (we might consider doing this admin-wide).
Last edited 15 months ago by lessbloat (previous) (diff)

comment:164 mordauk15 months ago

  • Cc pippin@… added

comment:165 follow-ups: travisnorthcutt15 months ago

In the Zero Menus State, I'm assuming from the presence of the "create menu" button that clicking that button (whether menu items are rearranged or not?) creates a new custom menu. Is that correct?

If so, I feel that may be a little confusing/non-obvious. Perhaps some copy explaining that this is the default menu (based on existing pages, right?), and that clicking the button saves it as a custom menu that can be edited, would be best?

comment:166 in reply to: ↑ 165 lessbloat15 months ago

Replying to travisnorthcutt:

In the Zero Menus State, I'm assuming from the presence of the "create menu" button that clicking that button (whether menu items are rearranged or not?) creates a new custom menu. Is that correct?

Yes, that is correct.

If so, I feel that may be a little confusing/non-obvious. Perhaps some copy explaining that this is the default menu (based on existing pages, right?), and that clicking the button saves it as a custom menu that can be edited, would be best?

That's a great idea. Will do.

lessbloat15 months ago

comment:167 in reply to: ↑ 165 lessbloat15 months ago

Replying to travisnorthcutt:

If so, I feel that may be a little confusing/non-obvious. Perhaps some copy explaining that this is the default menu (based on existing pages, right?), and that clicking the button saves it as a custom menu that can be edited, would be best?

23119.22.diff​ changes it to: "Edit your default menu by adding or removing items. Drag each item into the order you prefer. Click Create Menu to save your changes." (suggestions welcome).

I'll start testing 23119.22.diff​ this afternoon, and will post the results to: http://make.wordpress.org/core/2013/02/01/we-had-a-great-discussion-yesterday-during-office/

p.s. Menus office hours will be today at 21:00 UTC (in #wordpress-dev). Swing past if you have questions/concerns.

lessbloat15 months ago

comment:168 lessbloat15 months ago

The idea behind the "zero menu" state is that it simplifies the flow for the majority of new users (based on the assumption that their theme has a single theme location).

Upon clicking "Create Menu" in the "zero menu" state, 23119.23.diff​ auto-saves the users new menu as their primary theme location. This saves users from having to manually select a menu for their single theme location (at this point we know they only have one of each), thus streamlining the flow, and consolidating two steps into one.

Users with themes that have zero theme locations, or more than one theme location will not see the zero menus state, and are taken right to the add new screen if they don't have any menus.

comment:169 lessbloat15 months ago

I tested two more new users with 23119.23.diff​ applied. Overall, things went very smoothly, with only a couple of rough spots remaining.

Note: Here's our plan of attack for moving forward.

jkudish15 months ago

theme locations as checkboxes

jkudish15 months ago

theme locations as checkboxes screenshot 1

jkudish15 months ago

theme locations as checkboxes screenshot 2

comment:170 follow-ups: jkudish15 months ago

In 23119.24.diff I've added support for setting theme locations via checkboxes under 'Menu Settings'.

Note that this patch is sort of the minimal amount of work/code required to make this work, it can/needs to be cleaned up a bit and if we proceed with this approach we also need to remove the theme locations metabox code (which I've commented out the add_meta_box line for now + added a todo for)

Here's how the checkbox looks:

http://core.trac.wordpress.org/raw-attachment/ticket/23119/Screen%20Shot%202013-02-05%20at%2010.43.19%20PM.png

Here's it looks if a menu is already assigned to a location (adds a note under the checkbox):

http://core.trac.wordpress.org/raw-attachment/ticket/23119/Screen%20Shot%202013-02-05%20at%2010.43.33%20PM.png

Let me know what you think and if you can test this, please do and let me know if there's any issues.

I also have 2 unrelated notes of something I noticed with this latest patch that we should probably fix:

  • 'delete menu' link should be red
  • there should be some explanatory text under 'Menu Structure' before you add items to it, otherwise it's a very confusing heading on it's own

comment:171 in reply to: ↑ 170 ; follow-up: toscho15 months ago

Replying to jkudish:

In 23119.24.diff I've added support for setting theme locations via checkboxes under 'Menu Settings'.

How will that work when there are many theme locations, a dozen or so? Yes, that’s rare, but then it will look rather confusing, I guess.

comment:172 in reply to: ↑ 170 lessbloat15 months ago

Replying to jkudish:

In 23119.24.diff I've added support for setting theme locations via checkboxes under 'Menu Settings'.

Awesome. I'm excited to test this.

I also have 2 unrelated notes of something I noticed with this latest patch that we should probably fix:

  • 'delete menu' link should be red
  • there should be some explanatory text under 'Menu Structure' before you add items to it, otherwise it's a very confusing heading on it's own

Yep, I agree. both are valid, and should be addressed.

comment:173 in reply to: ↑ 171 ; follow-ups: lessbloat15 months ago

Replying to toscho:

How will that work when there are many theme locations, a dozen or so? Yes, that’s rare, but then it will look rather confusing, I guess.

Note: This is just a proposed concept (something we'll test with a couple users). If it flops in usability testing, we're back to square one.

The theme location checkboxes will just stack on top of each other. I would think a dozen would be extremely edge case. My guess is that the majority of themes have 1-3 theme locations. Thanks to Philip we have some data to back that up (my guess is that this same pattern is found in most wp.org themes as well).

I suppose we could add a hook in there, so theme devs could swap out the checkboxes for something else. But I suspect that if you're using a theme with 12 theme locations, you're a step above the average user, and you can likely figure out what's going on.

Last edited 15 months ago by lessbloat (previous) (diff)

comment:174 in reply to: ↑ 173 lessbloat15 months ago

Replying to lessbloat:

The theme location checkboxes will just stack on top of each other.

My mistake, jkudish coded them up horizontally:

http://f.cl.ly/items/3q1O02032E2X2H383k2d/theme-locations-checkboxes.jpg

Which I actually don't mind at all. I changed my mind after posting this. I feel like the checkboxes should stay stacked, as we're adding (currently uses 'Menu Name') in light gray next to one if it is used by another menu.

Last edited 15 months ago by lessbloat (previous) (diff)

comment:175 jkudish15 months ago

The horizontal alignment of the checkboxes was an accidental ommision, I meant to have them stacked vertically. Will submit a revised patch in a bit.

comment:176 in reply to: ↑ 173 toscho15 months ago

Replying to lessbloat:

The theme location checkboxes will just stack on top of each other. I would think a dozen would be extremely edge case.

For a regular blog, yes. When WP is used as a CMS, no. I had to do this multiple times: Custom menu locations for custom post types (sidebars in singular views) for custom roles and combinations of both.

I suppose we could add a hook in there, so theme devs could swap out the checkboxes for something else.

That would be very useful.

DrewAPicture15 months ago

Demo Plugin: Adds 3 theme locations

comment:177 DrewAPicture15 months ago

demo_theme_locations.php is a micro-plugin to add 3 additional theme locations for testing.

toscho15 months ago

23119.24.diff in latest trunk

lessbloat15 months ago

comment:178 lessbloat15 months ago

23119.24.1.diff just adds a few small tweaks:

  • Enabled ability to add menu items in the "zero menu" state.
  • Made delete link blue (it turns red on hover)
  • Added explanatory text back under 'Menu Structure' before you add items
  • If you create more than one menu, and Menu 1 is already assigned to a theme location, you'll see:

http://f.cl.ly/items/083I0N2t2p3U3c442i2E/menu-location-set.jpg

I'm open to copy/formatting suggestions for the "Set to" bit. We can also add a confirmation JS alert if they click the Primary box, asking if they're sure they want to switch the Primary theme location to this new menu (as it can only be set to one menu at a time).

Last edited 15 months ago by lessbloat (previous) (diff)

comment:179 in reply to: ↑ 95 ; follow-up: ceo15 months ago

This is a monster trac at this point and I'm not entirely sure I'm following it all, but with regard to this:

Replying to lessbloat:

2) pressing the right, left, up or down key.

Supports RTL. Supports moving single item as well as items with children (sub items). Ideally, it should behave identical to drag/drop. With that said, there is a lot going on here, so please ping me if you notice any issues.

Can you please elaborate on this functionality? From the standpoint of a blind person, how would I be moving this item and know where I'm moving it? Moving something without vision, even while only using the keyboard, seems to me something that would inherently require vision.

Whereas, for instance, ordering items in the accessibility mode of the widget screen relies on numbers to delineate where the widgets would be.

Last edited 15 months ago by ceo (previous) (diff)

comment:180 DrewAPicture15 months ago

@lessbloat: Looks like 23119.24.1.diff needs to be regenerated. It didn't come through correctly.

lessbloat15 months ago

comment:181 lessbloat15 months ago

23119.25.diff​:

  • makes the delete link red (thanks Nacin)
  • adds accordion styling to menu items (for testing)
  • adds RTL CSS
  • Removes headers in menu edit box (i.e. "Settings", and "Menu structure"), to reduce vertical space.
  • Moves the menu name field back up to the top bar. This saves us vertical space, and allows us to put the settings down below the menu structure section.

http://f.cl.ly/items/113V0e3Q3N100T1h3d2G/menus.25.jpg

Next, we'll run another round of usability testing, and then re-evaluate next steps based on the results.

comment:182 in reply to: ↑ 179 ; follow-up: lessbloat15 months ago

Replying to ceo:

This is a monster trac at this point

;-) Sorry, I take responsibility for that. I'm still learning how to use Trac effectively.

From the standpoint of a blind person, how would I be moving this item and know where I'm moving it? ... Whereas, for instance, ordering items in the accessibility mode of the widget screen relies on numbers to delineate where the widgets would be.

The only thing I've done is make it possible to rearrange the menu items via the keyboard (vs. requiring users to drag and drop menu items with a mouse). As you've pointed out, this improves accessibility for some users, but not all. To be honest, this is the first I've seen/heard of the accessibility mode in widgets.

For full disclosure, I'm really a novice when it comes to accessibility design. With that said, I'm eager to help where I can, so I appreciate your bringing this to my attention. A couple of questions:

  • If I set you up with a sandbox for testing with the latest (23119.25.diff​) patch applied, would you be wiling to make a list of all of the remaining in-accessible elements on the menu screen?
  • In the widgets accessibility mode, is going to a new screen to re-assign order helpful in that it removes other distractions, or was it just coded up that way?

comment:183 in reply to: ↑ 182 ceo15 months ago

Replying to lessbloat:

For full disclosure, I'm really a novice when it comes to accessibility design. With that said, I'm eager to help where I can, so I appreciate your bringing this to my attention. A couple of questions:

  • If I set you up with a sandbox for testing with the latest (23119.25.diff​) patch applied, would you be wiling to make a list of all of the remaining in-accessible elements on the menu screen?

Yes, provided you walk me through what I'd need to do on my end. The extent of my testing has been on nightly builds.

  • In the widgets accessibility mode, is going to a new screen to re-assign order helpful in that it removes other distractions, or was it just coded up that way?

I don't know; I wasn't part of testing this when it was being introduced.

comment:184 follow-up: DrewAPicture15 months ago

In working on the 'Locations in the dropdown' task, I noticed a bug with 23119.25.diff where theme locations can only be assigned for one of your menus at a time.

I made a short screencast to illustrate the problem.

http://screencast.com/t/kySUEuVR6U

  1. First I assigned the 'Primary Menu' location to the 'Main Menu' menu.
  1. Next, I assigned the 'Location 1' location to the 'Something' menu. Notice that upon saving, there is no longer a notation that 'Primary Menu' location is assigned to 'Main Menu'.
  1. Revisited the editing screen for 'Main Menu' menu and note that 'Primary Menu' location is unchecked and 'Location 1' is assigned to 'Something' menu.
  1. Last, I overrode the setting for 'Location 1' location for the 'Main Menu' menu. This works as expected and overrides the setting for the current menu.
Last edited 15 months ago by DrewAPicture (previous) (diff)

comment:185 in reply to: ↑ 184 jkudish15 months ago

Replying to DrewAPicture:

In working on the 'Locations in the dropdown' task, I noticed a bug with 23119.25.diff where theme locations can only be assigned for one of your menus at a time.

Oh that's a pretty bad bug. Thanks I'll work on a fix right now.

jkudish15 months ago

improve menu saving code and fix saving bug

comment:186 jkudish15 months ago

Fixed the bug that DrewAPicture found and improved the menu saving code in 23119.26.diff

comment:187 lessbloat15 months ago

Begininning to see the fruit of our labor in the latest round of usability tests. :-)

DrewAPicture15 months ago

Menu locations in dropdown

comment:188 DrewAPicture15 months ago

23119.27.diff adds the locations in a comma-separated list to the 'Selected menu' dropdown. I'd love to iterate the foreaches around L#462.

Also note:

  • I moved the $locations and $menu_locations bits up to about L#395 just below where we set $_nav_menu->truncated_name so I could reuse the arrays previously reserved for the locations checkboxes around L#555.

comment:189 DrewAPicture15 months ago

Locations in 'Selected menu' dropdown per 23119.27.diff:

http://f.cl.ly/items/0u2B1T1Z0o0F2q3U1N1y/Screen%20Shot%202013-02-07%20at%201.35.23%20PM.png

jkudish15 months ago

improves 23119.27.diff by removing an unneeded foreach loop

DrewAPicture15 months ago

Spacing issues in the foreach changes in 23119.28

DrewAPicture15 months ago

More complete docs for newly-introduced functions

DrewAPicture15 months ago

Limits locations in the dropdown to default 3 w/ filter.

comment:190 DrewAPicture15 months ago

  • 23119.28.1 fixed some spacing issues around the locations dropdown foreach
  • 23119.28.2 added more complete docs to new functions
  • 23119.28.3 limits the number of locations in the dropdown to a filterable default of 3 (per yesterday's office hours) with ellipses. Looks like this:

http://f.cl.ly/items/3n1E0M0T172M1Z3A1G0m/Screen%20Shot%202013-02-08%20at%203.31.55%20PM.png

Wasn't sure if I should do ", ..." or just " ...". English majors?

Last edited 15 months ago by DrewAPicture (previous) (diff)

DrewAPicture15 months ago

no-js CSS tweaks.

comment:191 follow-ups: DrewAPicture15 months ago

Some no-js observations:

  • There's no way to select menus from the drop-down. Perhaps a no-js button?
  • Header backgrounds in the accordion boxes are inconsistent due to .closed class being applied inconsistently.
  • Pointer needs to be switched to default in accordion box headers (fixed in 23119.28.4)
  • Extra 31px padding-top from #menu-settings-column (fixed in 23119.28.4)
  • There's a yellow "pending" menu-items message that shows reminding you to save. Might be worth looking at showing that regardless of js/no-js

Unrelated no-js nice-to-have:

  • Kinda lame that there's currently no way to make menu items into sub-items. Can only move them up and down.

General:

  • The 'Reset', formerly 'Cancel' link in menu-items has no effect in both js and no-js.

comment:192 in reply to: ↑ 191 ; follow-ups: grahamarmfield14 months ago

Replying to DrewAPicture:

Some no-js observations:

  • There's no way to select menus from the drop-down. Perhaps a no-js button?

It's difficult for me to fully comment on functionality from just a screenshot, but for accessibility reasons it is always desirable to have a 'Go' button of some sort when a select or drop-down is being used as a navigational device. Where the page or context changes purely triggered by the onchange event, this means that keyboard only users (including screen readers) will be triggering such functionality as they roll through the options in the select.

comment:193 in reply to: ↑ 191 lessbloat14 months ago

Thanks for reviewing those DrewAPicture.

Replying to DrewAPicture:

Unrelated no-js nice-to-have:

  • Kinda lame that there's currently no way to make menu items into sub-items. Can only move them up and down.

The down/up arrows should handle this as well (though it's not super intuitive). Just continue clicking an arrow in the same direction. At least that's the way it used to work.

General:

  • The 'Reset', formerly 'Cancel' link in menu-items has no effect in both js and no-js.

I'll look at this.

comment:194 in reply to: ↑ 192 lessbloat14 months ago

Replying to grahamarmfield:

For accessibility reasons it is always desirable to have a 'Go' button of some sort when a select or drop-down is being used.

Good call. I'll get that added in place of the current auto-redirect code. Thanks grahamarmfield!

lessbloat14 months ago

comment:195 lessbloat14 months ago

Changes in 23119.29.diff​ include:

  • Removed hacked in accordion code
  • Re-hid the menu select drop down when users only have one menu. It should only show when users have more than one menu.
  • Added a "Go" button for the menu selection drop down, and removed the auto-redirect code that was there.
  • Changed "Reset" back to "Cancel", and fixed it so that it works.
  • Hid "Cancel" link in no-js mode.
  • Updated notification message to show in no-js mode.
  • Reviewed CSS for this patch - moved all colors code to colors-fresh.css
  • Cross browser testing (Tested in Mac FF, Chrome, Safari & Win IE8, FF, Chrome)

It's code review time. If you've got some time I'd appreciate the help.

Last edited 14 months ago by lessbloat (previous) (diff)

lessbloat14 months ago

comment:196 lessbloat14 months ago

AaronCampbell did a quick at-a-glance code review, and found the following:

  • Looks like an accidental replacement of @uses with wp_n in the doc block
  • There's some commented out code in wp-admin/includes/nav-menu.php that should probably be removed instead of commented
  • There's a small amount of trailing whitespace, which should be removed
  • There are some strings that aren't translatable in wp-admin/nav-menus.php on line 451 (Menus, and Add New) and one line 483 (Go).  There may be more, but those are the ones I saw
  • In wp-admin/nav-menus.php on line 464 you're using esc_html in an attribute.  Use esc_attr instead.  This could happen other places, this is the one I noticed

Which I fixed in 23119.29.1.diff​.

Additional code reviews would be much appreciated (from multiple people). Thanks for your help!

comment:197 follow-up: aaroncampbell14 months ago

It looks like there's still some trailing whitespace. For example, wp-admin/js/nav-menu.js line 399 has only changed because there's a space at the end now. Whoever commits can probably fix it, but it's likely that you can set your editor to trim trailing whitespace automatically.

DrewAPicture14 months ago

Coding standards for new stuff, 6-digit hex codes in CSS colors, etc.

comment:198 DrewAPicture14 months ago

23119.29.2.diff fixes some coding standards on the new stuff, makes hex codes 6-digits on the CSS colors and some other small stuff.

Not sure I'm onboard with the 'Go' button on the dropdown select. I like that we have the button, but not 'Go'. I also think 'Selected menu' should change to maybe just 'Select menu', especially if we're adding a button. Thoughts?

lessbloat14 months ago

comment:199 in reply to: ↑ 197 lessbloat14 months ago

Replying to aaroncampbell:

It looks like there's still some trailing whitespace. For example, wp-admin/js/nav-menu.js line 399 has only changed because there's a space at the end now. Whoever commits can probably fix it, but it's likely that you can set your editor to trim trailing whitespace automatically.

Thanks for the tip. Found a plugin for Coda. As far as I can tell, 23119.29.3.diff​ should do the trick.

comment:200 follow-up: wonderboymusic14 months ago

my favorite plugin for Coda is called "Netbeans"

comment:201 in reply to: ↑ 200 lessbloat14 months ago

Replying to wonderboymusic:

my favorite plugin for Coda is called "Netbeans"

Heh... Nice.

As the 200th comment on this ticket you win the grand prize!!!

Congratulations wonderboymusic!

You get the honorary privilege of code reviewing 23119.29.3.diff​!!!

;-)

Last edited 14 months ago by lessbloat (previous) (diff)

comment:202 ocean9014 months ago

__('Add ') . $tax->labels->name is a no-go for translations. Needs sprintf() and _x().

jkudish14 months ago

code reviewed

comment:203 jkudish14 months ago

Code reviewed, and latest changes posted in 23119.30.diff. Here are my notes:

  • added missing absint() when saving menu items
  • made some minor code standards/spacing adjustments (both in php and in js)
  • adjusted the way we count the number of existing pages to use wp_count_posts() instead of get_pages() for performance reasons
  • using absint() when getting the recently edited menu instead of just (int), just to be safe
  • using empty() instead of just ! when checking if there is a recently edited menu, just to be safe
  • using empty() instead of comparing against 0 when checking if there is a currently selected menu
  • making use of selected() in the new menu selection dropdown instead of doing an if dance and manually echoing selected=selected
  • replaced a URL that we were manually building with ? to use add_query_arg() instead
  • addressed @ocean90's comment about the tax label name
  • removed some unneeded remove_query_arg()
  • fixed incorrect usage of esc_attr_e()
  • added missing escaping on one of the submit buttons
  • js: cached $(this) in a few spots that we missed it
  • js: yoda conditions
  • Note: I did not review the css
  • Note: Between wp-admin/nav-menus.php and wp-admin/includes/nav-menu.php we have a lot of code. We should probably take a closer look to see if there's any repetition, unused code and such to see if we can optimize a bit. This seemed like beyond the scope of this initial code review, so I didn't dig too deep for now.
Last edited 14 months ago by DrewAPicture (previous) (diff)

comment:204 follow-up: ocean9014 months ago

Bug: Click the Add New button or go directly to wp-admin/nav-menus.php?action=edit&menu=0. Now you have changed your mind and want to change the selected menu. Do it via the dropdown menu.

=> Only the Menu Name will change, but the items are still missing.


Not sure, but is wp_nav_menu_disabled_check() still needed? If so, the disabled() function should be called with the third argument, defined as false. Otherwise it will echoing the disabled attribute.

comment:205 in reply to: ↑ 204 DrewAPicture14 months ago

Replying to ocean90:

Not sure, but is wp_nav_menu_disabled_check() still needed? If so, the disabled() function should be called with the third argument, defined as false. Otherwise it will echoing the disabled attribute.

I wondered about that when I was writing docblocks for it, especially since we removed the meta box. But it was either A) new or B) moved so I added the docs.

comment:206 in reply to: ↑ 192 ; follow-up: lessbloat14 months ago

Replying to grahamarmfield:

Replying to DrewAPicture:

Some no-js observations:

  • There's no way to select menus from the drop-down. Perhaps a no-js button?

It's difficult for me to fully comment on functionality from just a screenshot, but for accessibility reasons it is always desirable to have a 'Go' button of some sort when a select or drop-down is being used as a navigational device. Where the page or context changes purely triggered by the onchange event, this means that keyboard only users (including screen readers) will be triggering such functionality as they roll through the options in the select.

grahamarmfield, it seems like the redirect on change would only take place upon selection of a select option, not just in browsing the select options. Can you please clarify which is the case for screen readers?

comment:207 in reply to: ↑ 206 ; follow-up: grahamarmfield14 months ago

Replying to lessbloat:

grahamarmfield, it seems like the redirect on change would only take place upon selection of a select option, not just in browsing the select options. Can you please clarify which is the case for screen readers?

For most keyboard only users, when encountering a dropdown they would use the up and down arrow keys to review the options. This (I believe) fires the onchange event whenever a new option is moved to. So hence my comment re context change triggered by onchange.

There is a keystroke combination in Windows that allows the dropdown to be opened and the options to be reviewed without firing the onchange event until the enter key is pressed. But this keystroke combination is not widely known and is therefore likely to be hardly used.

So if the change of context is not triggered by the onchange event, but instead by tabbing away from the dropdown (onblur?) then I guess we're into a bit of a grey area.

The issue with not providing a 'Go' or 'Select' (or whatever) button is not just a problem for keyboard and screen reader users. Those using speech recognition software also need to be catered for.

comment:208 in reply to: ↑ 207 toscho14 months ago

Replying to grahamarmfield:

For most keyboard only users, when encountering a dropdown they would use the up and down arrow keys to review the options. This (I believe) fires the onchange event whenever a new option is moved to. So hence my comment re context change triggered by onchange.

In most browsers it is Shift+Arrow. But you have to know in advance when you need that.

So if the change of context is not triggered by the onchange event, but instead by tabbing away from the dropdown (onblur?) then I guess we're into a bit of a grey area.

Would still not be a predictable behavior.

The issue with not providing a 'Go' or 'Select' (or whatever) button is not just a problem for keyboard and screen reader users. Those using speech recognition software also need to be catered for.

A button is also easier to use on a touch screen, because there is enough space around.

lessbloat14 months ago

comment:209 lessbloat14 months ago

23119.31.diff​ changes include:

  • Changes copy around menu selection drop down
  • Changed "Select menu to edit" container from span to label
  • Changes "Go" button to "Select"
  • Fixed "add new screen" bug mentioned in comment:204

comment:210 lessbloat14 months ago

  • Keywords commit added; needs-testing removed

aaroncampbell14 months ago

comment:211 aaroncampbell14 months ago

So I guess lessbloat has been manually incrementing his patch numbers. Just so you know, if you upload 23119.diff over and over, Trac will change it to 23119.2.diff, 23119.3.diff, etc.

Anyway, 23119.diff is based off 23119.31.refresh.diff. The only thing I did is take out the "Add %s" strings where %s was a post type name or taxonomy name. Strings like that aren't translatable. If it turns out that we need a string like that, it would need to be added to the labels array in get_taxonomy_labels() and get_post_type_labels(). Since it doesn't currently exist though, many plugins and themes won't be using it and a default might be worse than not having the word Add prepended.

DrewAPicture14 months ago

refresh 23119.diff (fuzz)

comment:212 markjaquith14 months ago

In 23441:

Improve the UX of the Nav Menus screen. Kill the tabs, and change to a
dropdown, unless you have zero or one menus (which is the most common),
in which case you jump right into editing your sole menu.

Do assignment to location using checkboxes in the main menu editing
section instead of the backwards menu => location assignment in a
random meta box.

More to come, but this gets us started.

props lessbloat, DrewAPicture, jkudish. see #23119

comment:213 follow-up: scribu14 months ago

Notice: Undefined offset: 0 in wp-admin/nav-menus.php on line 475

comment:214 in reply to: ↑ 213 DrewAPicture14 months ago

Replying to scribu:

Notice: Undefined offset: 0 in wp-admin/nav-menus.php on line 475

Mind expanding on what steps produced the notice?

comment:215 scribu14 months ago

Can't reproduce it anymore. Must have been some weird edge case when transitioning from the old screen.

comment:216 follow-up: ocean9014 months ago

  • Keywords needs-patch added; has-patch commit removed

What is the benefit of changing the metabox title Custom Link to Add Links? These are all links which can be added to a menu.

The prefix Add should be removed to be consistent with the other titles. IMO Custom should come back too, since there is still a way to get the old Link Manager back, which isn't meant here.

comment:217 in reply to: ↑ 216 ; follow-ups: lessbloat14 months ago

Replying to ocean90:

What is the benefit of changing the metabox title Custom Link to Add Links? These are all links which can be added to a menu.

The prefix Add should be removed to be consistent with the other titles. IMO Custom should come back too, since there is still a way to get the old Link Manager back, which isn't meant here.

One of the things we're still implementing is making the menu items into an accordion. This improves the experience by decreasing the chance that the user will have to scroll to access all of the menu item options.

One downside of having most of the menu items closed on the left side is that it becomes harder for a first time user to know what is going on there. "Custom link" doesn't really convey any action. By switching it to "Add links" I felt like the underlying functionality became more discoverable at a glance, and the concept became much more clear (that each of the accordion options on the left allow me to add menu items).

An alternative could be to add a header above the accordion, something like: "Add menu items". This would be less redundant in the use of the word "Add", but it would push the accordion options down (slightly), and make for much less of a balanced UI (right now it's squared off nicely with a straight line across the top of the menu items accordion box, all the way across to the menu editing box). Happy to take a stab at it, if we think that approach would be better.

comment:218 in reply to: ↑ 217 SergeyBiryukov14 months ago

Replying to lessbloat:

"Custom link" doesn't really convey any action.

How about "Add a Custom Link"?

comment:219 in reply to: ↑ 217 ; follow-up: ocean9014 months ago

Replying to lessbloat:

By switching it to "Add links" I felt like the underlying functionality became more discoverable at a glance, and the concept became much more clear

But then the question remains, why just for Links?

comment:220 follow-up: markoheijnen14 months ago

I'm seeing the notice Scribu had too. It's in the selectbox. Most likely because of the existing menu.

There is still going on something weird with that. I had to create a new menu first before I could look at the old one. It was just showing the page to create a new menu.

comment:221 in reply to: ↑ 220 DrewAPicture14 months ago

Replying to markoheijnen:

I'm seeing the notice Scribu had too. It's in the selectbox. Most likely because of the existing menu.

There is still going on something weird with that. I had to create a new menu first before I could look at the old one. It was just showing the page to create a new menu.

Was the existing menu assigned to a theme location?

comment:222 markoheijnen14 months ago

Good question. I don't know. The only thing I know is that it isn't anymore. Setting or unsetting the theme location doesn't make a difference

comment:223 DrewAPicture14 months ago

RE: the notice from comment:213 / comment:220:

Notice: Undefined offset: 0 in wp-admin/nav-menus.php on line 475

After a conversation in IRC, @markoheijnen pasted a var_dump of $menu_locations:

 <DrewAPicture> markoheijnen: Can you share a var_dump on $menu_locations from before the foreach?
 <markoheijnen> array(2) {
 <markoheijnen> [0]=>
 <markoheijnen> int(2)
 <markoheijnen> ["primary"]=>
 <markoheijnen> int(2)
 <markoheijnen> }

My best guess is there's a problem with set_theme_mod() setting an invalid, absint-ed menu location with a value of 0, which therefore translates into an undefined offset into the second foreach for the select box.

jkudish14 months ago

fixes php notices

comment:224 follow-up: jkudish14 months ago

I was getting a different error:

Warning: array_merge(): Argument #1 is not an array in /wp-admin/nav-menus.php on line 277

Which was caused by $menu_locations being set to false when it was empty. 23119.3.diff fixes both the notices that @markoheijnen and I were seeing

comment:225 follow-up: DrewAPicture14 months ago

23119.3.diff does the trick for the undefined offset and array_merge errors.

Also to note, there is a case of an "invisible" menu on a vanilla install. When you first visit Menus and create a new menu, it's saved but you're sent back to the Create Menu screen as though you don't have any menus.

As @jkudish notes, it's likely caused by $nav_menu_selected_id being empty without a menu_id in the URL.

jkudish14 months ago

fix missing select/dropdown of menus which was causing some menus to be invisible

comment:226 in reply to: ↑ 225 jkudish14 months ago

Replying to DrewAPicture:

23119.3.diff does the trick for the undefined offset and array_merge errors.

Also to note, there is a case of an "invisible" menu on a vanilla install. When you first visit Menus and create a new menu, it's saved but you're sent back to the Create Menu screen as though you don't have any menus.

As @jkudish notes, it's likely caused by $nav_menu_selected_id being empty without a menu_id in the URL.

23119.4.diff (which includes 23119.3.diff) should fix the "invisible" menu issue and make sure that we always display a menu if one exists.

comment:227 follow-up: DrewAPicture14 months ago

23119.4.diff does indeed fix the "invisible" menu problem.

Also two things:

  1. The UX is inconsistent for creating your first menu and creating a new menu. I feel like they should be the same or nearly so.
  1. Perhaps we should look at opening a new ticket and/or individual tickets for new stuff cropping up such as refactoring and/or docs, etc. When we hit what would be 23119.7, the incrementer will restart at 23119.32

comment:228 follow-up: ryanhellyer14 months ago

I totally misunderstood the UI here and couldn't figure out how to create a new menu. However, it was obvious once someone pointed it out to me. I'm unsure if this was just me being an idiot, or if there is a genuine UX problem. Currently I'm erring on the side of "Ryan being an idiot", but thought I'd point out my difficulties in case it has any impact on decisions here.

comment:229 in reply to: ↑ 228 ; follow-up: DrewAPicture14 months ago

Replying to ryanhellyer:

I totally misunderstood the UI here and couldn't figure out how to create a new menu. However, it was obvious once someone pointed it out to me. I'm unsure if this was just me being an idiot, or if there is a genuine UX problem. Currently I'm erring on the side of "Ryan being an idiot", but thought I'd point out my difficulties in case it has any impact on decisions here.

I agree with you. Even though having the 'Add Menu' button up in the header is consistent with the other UI screens, I feel like it's really not very discoverable up there. @markoheijnen didn't see it right away the other day either.

I'd be curious to see if user tests will confirm there's a discoverability problem.

comment:230 markoheijnen14 months ago

The most funny part with me was that I did add some menu's before but after removing all menu's I somehow couldn't see it anymore.

I disagree that is would be consistent with other UI screens. Those screens are just overviews so the call to action is completely different.

comment:231 atimmer14 months ago

  • Cc atimmer added

comment:232 in reply to: ↑ 224 SergeyBiryukov14 months ago

Replying to jkudish:

I was getting a different error:

Warning: array_merge(): Argument #1 is not an array in /wp-admin/nav-menus.php on line 277

Which was caused by $menu_locations being set to false when it was empty.

Also reported in #23508.

comment:233 SergeyBiryukov14 months ago

In 23453:

Fix a warning on Menus screen if $menu_locations is false.
Fix menu selection after creating a first menu on new install.

props jkudish.
fixes #23508. see #23119.

comment:234 SergeyBiryukov14 months ago

  • Keywords needs-patch removed
  • Resolution set to fixed
  • Status changed from new to closed

Please open new tickets for any new issues.

comment:235 in reply to: ↑ 219 lessbloat14 months ago

Replying to ocean90:

Replying to lessbloat:

By switching it to "Add links" I felt like the underlying functionality became more discoverable at a glance, and the concept became much more clear

But then the question remains, why just for Links?

I had "Add" in there for all of them. Looks like they were ripped out for translation purposes.

comment:236 in reply to: ↑ 227 lessbloat14 months ago

Replying to DrewAPicture:

23119.4.diff does indeed fix the "invisible" menu problem.

Also two things:

  1. The UX is inconsistent for creating your first menu and creating a new menu. I feel like they should be the same or nearly so.

Open to additional thoughts on this, but this was actually intentional. For your first menu we preload all of the menu items that show in your theme by default (before you add our first menu). We do this out of convenience. When you click the "add new" link, I don't think we should preload any menu items. If you'd like to add a menu for a menu widget, you should be able to do so without first having to remove a bunch of menu items.

  1. Perhaps we should look at opening a new ticket and/or individual tickets for new stuff cropping up such as refactoring and/or docs, etc. When we hit what would be 23119.7, the incrementer will restart at 23119.32

Agreed.

comment:237 in reply to: ↑ 229 lessbloat14 months ago

Open to suggestions for the "add new" link. My feeling was that we should keep it consistent with the rest of the add new links in the admin.

comment:238 bobbravo214 months ago

Moved to new ticket: #23595

Last edited 14 months ago by SergeyBiryukov (previous) (diff)

comment:239 DrewAPicture14 months ago

  • Keywords needs-codex added

comment:240 nacin13 months ago

In 23897:

Remove _wp_delete_nav_menu(). wp_delete_nav_menu() should instead remove the menu from theme locations, which was the only difference between the functions. see #23119.

comment:241 SergeyBiryukov13 months ago

In 23941:

Use correct variable. fixes #24014. see #23119.

comment:242 markjaquith11 months ago

In 24356:

Remove unnecessary parenthetical that should have been "e.g." instead of "i.e." anyway.

see #23119

Note: See TracTickets for help on using tickets.