WordPress.org

Make WordPress Core

Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#23770 closed enhancement (fixed)

Restore 'Locations' meta box functionality as secondary tab in Menus UI

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

Description (last modified by DrewAPicture)

Following discussions on #23716, a positive set of user tests, and an IRC chat last night, we've opted to go with re-adding the 'Theme Locations' functionality using a tabbed approach in the Menus UI.

This would be geared more toward power users and would serve as secondary functionality to the checkboxes UI introduced in [23441]. It would allow power users to change all theme location settings at once just like in pre-3.6.

@markjaquith provided a rough mockup of the secondary theme locations UI here: http://cl.ly/image/3u1x2i1W3W2t

Menus UI Refresh tracking ticket: #23607

Attachments (10)

23770.diff (3.3 KB) - added by lessbloat 2 years ago.
23770.2.diff (8.7 KB) - added by DrewAPicture 2 years ago.
List table first-pass
23770.3.diff (8.1 KB) - added by DrewAPicture 2 years ago.
Doesn't use WP_List_Table, more flexibility and less code.
23770.4.diff (9.3 KB) - added by DrewAPicture 2 years ago.
23770.5.diff (11.1 KB) - added by lessbloat 2 years ago.
23770.6.diff (12.2 KB) - added by DrewAPicture 2 years ago.
Match menu ids to Edit link + RTL
23770.7.diff (12.0 KB) - added by markjaquith 2 years ago.
23770.8.diff (12.0 KB) - added by markjaquith 2 years ago.
23770.9.diff (13.6 KB) - added by markjaquith 2 years ago.
23770.10.diff (13.7 KB) - added by markjaquith 2 years ago.

Download all attachments as: .zip

Change History (36)

comment:1 @DrewAPicture2 years ago

  • Owner set to lessbloat
  • Status changed from new to assigned

comment:2 @DrewAPicture2 years ago

  • Keywords 3.6-menus added

comment:3 @DrewAPicture2 years ago

  • Description modified (diff)

comment:4 @DrewAPicture2 years ago

A little while ago, I showed the new UI to a friend and she made a very valid point. The locations meta box served dual purposes:

  1. To tell you how many menus your theme supports
  2. To set locations

I think we've completely overlooked the former. It would be nice to have a default-tab, front-facing way to tell people how many menus their theme supports. Any suggestions on placement?

@lessbloat2 years ago

comment:5 @lessbloat2 years ago

Added the two tabs in with 23770.diff​. Had to remove the extra "Add new" button as a result. Took a look at adding the manage locations table Mark mocked up, but I think it's a bit above my PHP comfort level. Anyone else up for tackling that?

comment:6 @DrewAPicture2 years ago

  • Keywords has-patch added; needs-patch removed

All this time in the "menu locations" debate, we've been trying to find a way to differentiate the previous UI of assigning menu locations from a mis-placed meta box.

Every solution we came up with involved pairing "some text (location)" with some "some text (menu name)". The thing is, to repeat an old saying, pictures are worth a thousand words.

In a short chat in IRC last night, @helen said something that struck my fancy. Theme authors have for years been using image as radio button options for things like choosing footer and site layouts in theme options.

We did it for the default layout in Twenty Eleven:
http://f.cl.ly/items/2p1Q18201c450j1F1L18/Screen%20Shot%202013-03-16%20at%2012.13.31%20PM.png

So why not apply that logic of "visual vs text" to theme locations?

I worked up a couple of mockups to illustrate the point. We're talking about this 'Manage Locations' tab as a secondary settings panel for power users. Perhaps we should look at it as more of a primary option for when you have more than say two menu locations?

The locations icons could be a very generic sprite that could be overridden by themes.

Food for thought:

http://f.cl.ly/items/1W1G2w09070Z2I3C461Q/menu-locations-text.png

http://f.cl.ly/items/021z2E383r361w1E0r3e/menu-locations-switch.png

Version 0, edited 2 years ago by DrewAPicture (next)

comment:7 @alex-ye2 years ago

  • Cc nashwan.doaqan@… added

I liked the idea of secondary tab here , but I disagree with #comment:6 or maybe I didn't understand him very well , The idea is good but it needs more organizing .

It may be cool if we extend register_nav_menu() function to set description , Icon image , ... etc , and I think we should show the secondary tab always or when there are 2+ locations

comment:8 follow-up: @helen2 years ago

I don't think we should be including "generic" icons. There's not really any such thing as a generic layout, and perpetuating that idea just leads to more "all WordPress sites look the same" naysaying.

I'm also not completely sure this is a primary screen for 2+ menus - are you thinking that it's a primary screen as in it's a good entry point for finding the menu you want to be editing when you have more than one? If so, then we'd have to look at adding the rest of created menus to the listing (let's say list table, for the moment). Could maybe be split between top (locations) and bottom (the rest).

comment:9 in reply to: ↑ 8 ; follow-up: @DrewAPicture2 years ago

Replying to helen:

I don't think we should be including "generic" icons. There's not really any such thing as a generic layout, and perpetuating that idea just leads to more "all WordPress sites look the same" naysaying.

That's a good point. It's like, how do you buttonhole millions of sites all into one sprite of icons? It's impossible.

I'm also not completely sure this is a primary screen for 2+ menus - are you thinking that it's a primary screen as in it's a good entry point for finding the menu you want to be editing when you have more than one?

No. The concept I laid out was to make the tab "primary" only in the context of setting multiple locations. But that wouldn't really work if we're trying to enforce this idea of it being a secondary UI, no? The mockups were merely a brief bit of inspiration, an idea in a sea of ideas.

In a round-about way, I'm suggesting that this 'Manage Locations' tab should only become available if you actually have multiple locations to set (since that's the power user use case we're trying to accommodate). Whether "multiple" means 2+ or 3+ is up for discussion.

comment:10 in reply to: ↑ 9 @lessbloat2 years ago

Replying to DrewAPicture:

So why not apply that logic of "visual vs text" to theme locations?

I really dig the concept. But let's leave it for a future release. Too late in the release to try and tackle it this time around.

In a round-about way, I'm suggesting that this 'Manage Locations' tab should only become available if you actually have multiple locations to set

I'd hide it only when $one_theme_location_no_menus = true (the zero menus state). After that, they should have access to the tab. Once they've added a menu, I'd show it.

comment:11 follow-up: @DrewAPicture2 years ago

23770.2.diff takes a pretty rough first stab at using a list table for the locations tab.

There are several details to work out as we move forward:

Saving:

  • I left the 'Save' button out for the first pass.
  • We don't really use a list table in a global fashion (outside of Bulk Options) anywhere else, so should we do in-row saves, bulk option saves or an overall save?
  • If we go with an overall save option, ideas on placement?

TODOs:

  • There are dummy links in the 'Assigned Menus' column that need real URLs.
  • Would be nice if we had a short blurb of explanatory text at the top. Should be simple once we get the experience ironed out.
  • selected() in the selects doesn't work, should be fixed in the next pass.
  • The 'Assigned Menus' column could generally benefit from the experienced hands of a UI person.
  • Add docblocks in the list table class
  • There's a JS error on the page:
    ReferenceError: menu is not defined /wp-admin/js/nav-menu.js?ver=3.6-alpha-23751 
    Line 48
    

After first-pass:

http://f.cl.ly/items/1I322q1V251U2V1k0i2l/Screen%20Shot%202013-03-19%20at%206.28.37%20PM.png

@DrewAPicture2 years ago

List table first-pass

comment:12 in reply to: ↑ 11 @SergeyBiryukov2 years ago

Replying to DrewAPicture:

ReferenceError: menu is not defined /wp-admin/js/nav-menu.js?ver=3.6-alpha-23751 
Line 48

Should be fixed in [23760].

@DrewAPicture2 years ago

Doesn't use WP_List_Table, more flexibility and less code.

comment:13 @DrewAPicture2 years ago

23770.3.diff opts to forgo extending WP_List_Table, instead building our own table similarly to how we already do in update-core.php. This is for a couple of reasons:

  1. We don't use a list table in a global-save capacity any where else in the admin.
  2. It's easier to control the layout.
  3. We don't need pagination, search, filtering or most of the other benefits WP_List_Table affords.

TODO:

  • Add a nonce for the locations action (not sure how to handle this because the tab is the action but we're saving via the tab.
  • Add a 'Locations Updated' message.
  • Figure out best placement of the save button(s).
  • Fix hiding edit links for locations with no assigned menu
  • Add contextual help text.
  • Hide the main-tab screen options and/or help text in the locations tab.

I'd also like to look at listing the number of menus "your theme supports" like we did previously in the meta box.

The table as of 23770.3.diff:

http://f.cl.ly/items/2O0p1b0K3X1J160q3u1c/Screen%20Shot%202013-03-21%20at%2010.57.50%20AM.png

comment:14 @helen2 years ago

UI thoughts: column titles should be singular, as they are in other places, and the Save Locations button should be on the left, possibly both above and below, and should probably be labeled "Save Changes". Also, the Edit link shouldn't appear unless there's a menu assigned, and should also disappear if the select value changes; otherwise you are sent away from the screen without having saved the changes. Not sure what that will mean for no-JS, but we can sort that out.

@DrewAPicture2 years ago

comment:15 @DrewAPicture2 years ago

Replying to helen:

UI thoughts: column titles should be singular, as they are in other places, and the Save Locations button should be on the left, possibly both above and below, and should probably be labeled "Save Changes".

All of the above are covered in 23770.4.diff.

The patch also:

  • Adds a nonce on the form
  • Adds a 'Menu locations updated' message on save
  • Hides screen options for this tab (all irrelevant)

Also, the Edit link shouldn't appear unless there's a menu assigned, and should also disappear if the select value changes; otherwise you are sent away from the screen without having saved the changes. Not sure what that will mean for no-JS, but we can sort that out.

@lessbloat offered to handle the JS for hiding/showing the edit links, so that's forthcoming. We'll also need to handle passing the correct menu id based on what's selected.

The UI as of 23770.4.diff:

http://f.cl.ly/items/1s22413A1x08171O1E37/Screen%20Shot%202013-03-22%20at%203.48.13%20AM.png

@lessbloat2 years ago

comment:16 @lessbloat2 years ago

Nice work Drew!

Changes in 23770.5.diff​:

  • Various CSS tweaks
  • Hide "edit" when no menu is selected
  • Hide "edit" on change, and added "Are you sure…" notification if they leave without saving
  • Changed "Add new" to "Use new menu". Open to additional improvements here.

Still left:

  • RTL
  • When you click "Use new menu" and you create one, we should auto-assign that menu to the theme location they clicked "Use new menu" under.

@DrewAPicture2 years ago

Match menu ids to Edit link + RTL

comment:17 @DrewAPicture2 years ago

23770.6.diff matches the proper menu id to the Edit links and adds RTL fixes.

comment:18 @markjaquith2 years ago

When you save on the locations page, the onunload code kicks in and AYSes you.

@markjaquith2 years ago

comment:19 @markjaquith2 years ago

Refresh to resolve conflicts. Removed the top save button. Seems superfluous. Commented out the tfoot — also seems superfluous.

@markjaquith2 years ago

comment:20 @markjaquith2 years ago

Fixes the AYS on Locations Save bug by ignoring changes to its select dropdowns. Fixes the issue where all Edit links would go away by limiting the jQuery selector to the current table row.

@markjaquith2 years ago

comment:21 @DrewAPicture2 years ago

Seems like it's basically working as expected after 23770.9.diff. As I mentioned in IRC, the only thing I see out of place is that the AYS doesn't fire anymore when you leave after making changes.

@markjaquith2 years ago

comment:22 @DrewAPicture2 years ago

23770.10.diff works as expected for me. Nice work!

comment:23 @lessbloat2 years ago

Tested 23770.10.diff. Looks good.

comment:24 @markjaquith2 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

In 23810:

Move nav menus to a tabbed interface, so that users with a lot of locations can do bulk assignment.

props DrewAPicture, lessbloat. fixes #23770

comment:25 @DrewAPicture2 years ago

  • Keywords needs-codex added

comment:26 @nhuja2 years ago

I wanted to post this earlier but saw the ticket was closed. I strongly feel that moving existing functionality to different place is confusing. I was confused for a while and people I have worked with were to. I had 2 users in WordPress.com who couldn't get the menu up. While I understand that if the user has a lot of menus, it looks disorganized but even for 1-2 menus which 90% of the people will have, this is one extra step. BAD UI.

If I switch themes (and not all themes have same menu name), the menu gets deselected from the Locations. Hence only default (Page) menu appears. It was easy to change it pre 3.6 because, it was on the same page. Now you have to click another page and select it there. Its one more step and for slow connections like me, working on LIVE site can take some more seconds. A good UI is not a good design. Its how easy you can get it to the end user. We should consider that. Its just one little box and moving that entirely to another page doesn't really explain it.

And another confusing thing was the Edit menu option. I first thought that was where you select the menu (location), until I read it carefully. These are small things on how many people these days feel WordPress is getting "complicated" than it should. Ask anyone.. :)

Just posting my thoughts here. Thanks Lance for directing me to this page.

Note: See TracTickets for help on using tickets.