#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 )
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)
Change History (36)
#5
@
12 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?
#6
@
12 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:
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:
'Edit Menus' tab:
http://cl.ly/image/0Y3t1h2K2m1x
'Manage Locations' tab:
http://cl.ly/image/323H3c1K0D2f
Edit: Linked the mockups instead of embedding them, don't want to distract from the rest of the ticket.
#7
@
12 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
#8
follow-up:
↓ 9
@
12 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).
#9
in reply to:
↑ 8
;
follow-up:
↓ 10
@
12 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.
#10
in reply to:
↑ 9
@
12 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.
#11
follow-up:
↓ 12
@
12 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:
#12
in reply to:
↑ 11
@
12 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].
#13
@
12 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:
- We don't use a list table in a global-save capacity any where else in the admin.
- It's easier to control the layout.
- 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:
#14
@
12 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.
#15
@
12 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:
#16
@
12 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.
#17
@
12 years ago
23770.6.diff matches the proper menu id to the Edit links and adds RTL fixes.
#19
@
12 years ago
Refresh to resolve conflicts. Removed the top save button. Seems superfluous. Commented out the tfoot — also seems superfluous.
#20
@
12 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.
#21
@
12 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.
#22
@
12 years ago
23770.10.diff works as expected for me. Nice work!
#26
@
12 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.
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:
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?