WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Tagged: menus Toggle Comment Threads | Keyboard Shortcuts

  • lessbloat 5:26 pm on February 8, 2013 Permalink
    Tags: , menus   

    Menus Office Hours (Feb 7) 

    Here’s a recap of yesterdays office hours.

    Work accomplished since last office hours

    Major items discussed

    1) Theme locations continues to be our biggest design challenge. We discussed a bunch of options and decided to go with checkboxes for theme locations for now – while we continue to stew on alternative approaches.

    2) We discussed having settings at the top or the bottom, and settled on them being on the bottom.

    On the docket

    • Refactor accordion code (@lessbloat)
    • Re-assess CSS in latest patch (currently 23119.28.1.diff), and move colors to colors.css (Looking for a volunteer here)
    • Browser compat testing (Looking for a volunteer here)
    • No JS testing (Looking for a volunteer here)
    • Code review (Looking for volunteers here – hopefully from multiple people)
    • Commit what we’ve got

    After that

    • Any additional accessibility work
    • Additional code refactoring
    • Am I missing anything?

    p.s. @DrewAPicture, I added a title this time just for you. ;-)

     
    • Drew Jaynes (DrewAPicture) 5:57 pm on February 8, 2013 Permalink | Log in to Reply

      RE: title, “He can be taught!”

      We also need to do an extensive round of RTL testing as well as completing docblocks for any new functions we’re introducing, @access private or not.

      I can start on no-js testing this weekend.

    • sireneweb 4:50 pm on February 11, 2013 Permalink | Log in to Reply

      Hi, very nice :)
      When you use Mega drop down menu, you can’t delete all children from main menu. It would be great if we can Expand/Collaspe main menu and delete all children sub menu from main menu

      • lessbloat 6:14 pm on February 11, 2013 Permalink | Log in to Reply

        I asked @jkudish to gather some data around avg number of menu items per menu for sites on WP.com. Out of 1000 random sites (with at least one menu added), here’s what the distribution looked like:

        Excluding the menus with zero items added, the average comes out to 5.

        So, based on this data, should we make some sort of expand/collaspe menu item functionality a part of core, or keep it in plugin territory?

        I think my preference would be to keep it as a plugin, but I’d love to hear everyones thoughts.

  • lessbloat 4:41 pm on February 1, 2013 Permalink
    Tags: , menus   

    We had a great discussion yesterday during office hours. I’m excited to say that we’ve found our direction.

    We’ll only be focusing on changes to nav-menus.php for now.

    I just posted an updated diff containing some of the ideas we discussed.

    Remaining Tasks (already assigned to someone)

    • Test theme locations as checkboxes (@jkudish volunteered to code this up). Note: we decided to leave widgets as checkboxes out.
    • Menu selection dropdown should show location(s) it is used in (@DrewAPicture offered to tackle this)
    • A round of user tests on 23119.23.diff, plus additional testing once “theme locations as checkboxes” and the accordion code is ready
    • 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)

    Remaining Tasks (still needing a volunteer)

    • Code up menu item boxes as an accordion for us to test (similar in style to customizer).
    • Code reviews (multiple people please :-))
    • RTL testing
    • Browser compatibility testing
    • No JS testing

    Comment below if you’re interested in helping out. Thanks!

     
    • Joey Kudish 4:46 pm on February 1, 2013 Permalink | Log in to Reply

      In addition to the checkboxes, I’ll help out with code reviewing and all the testing :)

    • Jon Brown 5:53 pm on February 1, 2013 Permalink | Log in to Reply

      I agree that the checkboxes shouldn’t be there for widgets, that’s be very confusing IMHO. However, maybe there should be a little tool tip or note below theme locations directing users that “Menus can also be added tomwidget areas via the custom menu widget available on the widget settings page”.

    • Travis Northcutt 12:18 am on February 2, 2013 Permalink | Log in to Reply

      @lessbloat, what is the “deadline” for getting the accordion done for testing?

      • lessbloat 1:14 pm on February 4, 2013 Permalink | Log in to Reply

        I’d like to wrap up all dev for this feature ASAP. I’ll likely pick it up if no one else grabs it by tomorrow.

  • lessbloat 2:53 pm on January 29, 2013 Permalink
    Tags: , menus   

    Menus office hours recap (Jan 28) 

    We’re still in the process of determining the best direction for menus in 3.6 (mock ups and ideas welcome!).

    My hope is that we can stay true to the WordPress Philosophy by optimizing the experience for the majority of users, and leaving edge cases for plugins to handle.

    One issue at this stage is that I can only guess as to what the majority looks like. I’m going to attempt to gather some data from WordPress.com as to how many users have one menu vs. more than one vs. none. This should give us some additional insight into the best way to approach menus.

    For this weeks meeting my goal was to list out, and then (roughly) prioritize the biggest pain points associated with menus. Since I have little data at this point, this prioritization is based on the assumption that the vast majority of users have either no menus or one menu.

    Here’s how I prioritized things, please weigh in if you disagree:

    • One of the biggest disconnects I’ve seen is the concept of “theme locations”. Adding a menu, and then assigning it to a theme location seems broken.
    • Trying to have menu management + editing + theme location assignment all on the same page is overwhelming.
    • Tabs don’t work for users with lots of menus to manage, and they confuse some users (who think they represent menu items within a single menu). Side note: when we tested menu management via a drop down (instead of tabs), users didn’t notice the drop down, and wondered where the menus they had already created were. A “manage menus” tab appears to work for users, but it seems heavy for users with just a single menu.
    • Switching themes poses a problem for menus in that there is no concept of a base menu. Every theme determines their own default menu, and even though two menus may have a single primary menu, you still have to re-assign your menu to that theme location whenever you switch a theme.
    • Users have a hard time visualizing how the menu changes they are making actually impact their blog/site.
    • Having to scroll to see all of the menu item meta boxes in the left column can be annoying, and it can make discoverability for items below the fold harder.
    • If you have a long menu (with lot’s of menu items), you may be scrolling unreasonably down from the left to the right column.
    • The fact that you can add menus to a custom menu widget is not exposed anywhere.

    Did I miss anything?

     
    • cvernon 3:26 pm on January 29, 2013 Permalink | Log in to Reply

      1.
      I agree theme locations isn’t working as it is now defined and managed.

      Most sites I make & use have only one menu, so I do not declare theme locations at all in the theme. This is how it should work, that you don’t need to understand the concept of theme locations unless you have many menus and know how you want to organize them. This should all be hidden by default.

      I like the idea of have the “base menu” concept just be a single menu that is not assigned a theme location, OR no menu at all in which case the fallback is to pull from all pages structure. Then if someone wants to get more complicated there should be another level of complication with multiple menus, in which case we want theme locations.

      2.
      Also, the way the wp_nav_menu() behaves differently [generates different html, accepts different arguments] whether or not any menu is declared [just takes the existing pages], or whether the menu is assigned to a theme location. This is a template tag issue but relates to how menus are managed in the admin & database.

    • deltafactory 3:41 pm on January 29, 2013 Permalink | Log in to Reply

      I agree with every point here. Two more thoughts, based more in the plugin/api area:

      The steps required to implement a “custom menu widget” are not obvious. At first glance at the code, it seems to rely on a complex interaction of both PHP and Javascript. The solution might be in documentation rather than changes to the code, but it’s still an area I would like to see improved.

      I would really like to see some additional filters to enable better caching alternatives. Even with an object cache, constructing a large menu results in a high number of cache hits. I have seen some opportunities to cache the menu item objects or even static HTML and greatly improve that part of the page output.

      If these requests aren’t out of scope, I can assist/suggest specific changes to code.

      • Bob Gregor 10:00 pm on January 29, 2013 Permalink | Log in to Reply

        +1 on the unclear menu management API! I had almost forgotten how I had to reverse engineer the custom menu widget to create a plugin menu item interface. Not clear at all.

    • Philip Arthur Moore 3:43 pm on January 29, 2013 Permalink | Log in to Reply

      One issue at this stage is that I can only guess as to what the majority looks like. I’m going to attempt to gather some data from WordPress.com as to how many users have one menu vs. more than one vs. none. This should give us some additional insight into the best way to approach menus.

      If my quick-and-dirty digging is correct, then only a very tiny handful of themes on WordPress.com use more than one menu in any significant manner, which means that the number of users who use more than one menu should be even smaller.

      I’d highly recommend approaching this problem with the direction that users will primarily need one custom menu for their blog, with the caveat that I’m sure the case could be made for more if a theme is more CMS-centric.

      • lessbloat 4:14 pm on January 29, 2013 Permalink | Log in to Reply

        Thanks for pulling this together Philip!

        If my quick-and-dirty digging is correct, then only a very tiny handful of themes on WordPress.com use more than one menu in any significant manner

        A couple thoughts:

        • My guess is that this is true for themes in general. So, I’m not sure how far off it is compared to wp.org usage.
        • Menus can also be added within widgets. My guess is that out of users who have multiple menus, chances are the majority of them only have one theme location menu, in addition to one or more custom menu widgets (again, just a hunch).
        • Even if all we get out of this is a better picture of how many users have no menus vs. one menu, I’d still find that hugely insightful.

        I’d highly recommend approaching this problem with the direction that users will primarily need one custom menu for their blog

        My gut agrees with you 100%. But it never hurts to at least attempt to back assumptions up with some data ;-)

        • Bob Gregor 10:02 pm on January 29, 2013 Permalink | Log in to Reply

          My experience with theme / custom WordPress development has shown that 98% of my client sites (wp.org) use just 1 menu location / no menu widgets.

        • Ricky Lee 12:23 am on January 31, 2013 Permalink | Log in to Reply

          Having built close to 100 themes since release of Menus, I can say 1 primary and 30% of time using depth=1 for footer menu is correct. Just started using Theme Location attribute since switching to _s as our base theme before we gave clients Editor level permissions and named menu “Main”.

    • Frankie Jarrett 4:01 pm on January 29, 2013 Permalink | Log in to Reply

      Great to see this list of pain ponts in priority. The more I think about it, the more I am liking the concept of a “base menu”.

      I just have a few more to add, which could perhaps fall under something already mentioned above, but I wanted to mention them anyway.

      1. Some users are finding it difficult to figure out how to nest menu items and create levels. There is no visual representation on the Menus screen that would suggest items can be clicked and dragged to the right to perform nesting.

      2. When adding a new item to a menu it is automatically appended to the end. This can create headaches for menus that are very long. It would be great to see the UI supporting drag and drop of the items directly into the menu list, similar to how widgets are placed in a sidebar area.

      3. Requiring that users go to Screen Options in order to select additional item fields (class, description, etc.) seems counterintuitive. It would seem that a simple “view more/view less” accordion could reveal the additional fields on a per-item basis.

    • Joey Kudish 4:58 pm on January 29, 2013 Permalink | Log in to Reply

      I’m going to attempt to gather some data from WordPress.com as to how many users have one menu vs. more than one vs. none.

      I went ahead and got this data for you. I selected 4 random sets of 1000 WordPress.com blogs that have had wp-admin activity in the month of January 2013. I then calculated for each blog how many menus they have (total, so regardless of how that menu is being used) and collated the results. 75.78% of blogs have no menus; 18.23% have 1 menu; 5.925% have more than 1 menu.

      I put together the full breakdown of my calculations here: https://docs.google.com/spreadsheet/ccc?key=0AszYZoR3BU_jdHJmZHRTQ19PcGdHSWhhempWRzBDeHc#gid=0.

      Let’s keep in mind that this is WordPress.com users and not self-hosted users, and I suspect there is a significant higher amount of “power users” on the .org side, who use menus differently, via widgets (which is possible on WP.com), and by calling directly wp_nav_menu in their custom themes/plugins (which is not possible on WP.com).

      Hope this helps with deciding how to proceed.

      • lessbloat 5:48 pm on January 29, 2013 Permalink | Log in to Reply

        Very cool. Thanks so much for tackling this @jkudish! Even with your disclaimers in mind, I find this data insightful.

        Here’s a pie chart of the breakdown:

    • Jon Brown 5:50 pm on January 29, 2013 Permalink | Log in to Reply

      Maybe a crazy idea and maybe overly influenced by my personal preference for building on Genesis… But what about getting rid of theme locations all together in favor of a single primary menu location that automatic tied to the primary menu and making the rest widget areas? (note I think the widget UI is in far greater need of a make over than the menus, but that’s definitely OT here). My initial thought is additional menu areas would show up on the widget page and custom menu widget widgets could be dragged in?

      I’d thought a while back that menus should be more like links were. An interface to build the link list/menu, but not the interface that actually places menus/links on the page/theme.

      Note, don’t know that I love the idea, I typically build custom themes with 3 menu areas (above header, below header, footer), but separating placement of menus and construction of menus sounds like a great idea.

    • lessbloat 8:32 pm on January 29, 2013 Permalink | Log in to Reply

      So, what if we used the number of menus a user has to determine what they should see. Here are my latest thoughts:

      If they have 0 menus

      About 76% of users would see this (based on WordPress.com’s stats).

      They’d see:

      • We’d auto populate the “blank slate” view with all of their existing pages. However, this menu is not actually created until they click “Save Menu”. If they navigate away from this page without clicking “Save Menu”, they will still technically have zero menus.
      • If they have only one theme location, we’d just use the theme location name (i.e. primary) as the menu name, and we’d auto assign this menu to their theme location upon saving.
      • We’d hide all “manage menus” functionality
      • And test using an accordion for the menu item options on the left (vs. meta boxes).

      So, if a user (with zero menus) came to the screen above, and immediately clicked “Save Menu”, they’d see:

      If they have 1 menu

      About 18% of users (based on WordPress.com’s stats).

      They’d see

      • We’d take them directly to the edit screen for that menu.
      • We’d hide all “manage menus” functionality

      So, based on the above approach (and the stats from WordPress.com), 94% of users would never see the management screen.

      If they have more than 1 menu

      After landing on menus, they’d see something like this:

      Clicking on a menu would take them to something like:

      Clicking the blue “Menus” header link (vs. showing tabs here), or the “menus” link under “Appearance” in the left nav would take them back to the manage menus view.

      When adding a menu

      Users would see:

      and then after creating their menu, if they had a single menu:

      If they had multiple menus, we’d link up “Menus” in the header.

      Other considerations

      Switching themes

      If a user has one menu, and the new theme has one theme location, and the user has no custom menu widgets, can we just auto-assign the existing menu to the theme location upon switching?

      Long menus (with lot’s of items)

      This makes menus hard to manage because you have to scroll to see all of your menu items, and when you add new menu items, they are added to the bottom by default.

      My preference (again based on usage stats) would be to keep this in plugin territory. This seems like it would make a great little plugin that could:

      1) Add collapsable tree functionality for menu items
      2) modify the “Add to Menu” button under each menu option to be a split button “Add to top”/”Add to Bottom”, and
      3) include drag and drop of menu items from the left.

      I don’t feel like this functionality should be exposed to the majority of users.

      Thoughts?

      • Joey Kudish 8:57 pm on January 29, 2013 Permalink | Log in to Reply

        This seems like the logical way to proceed based on everything that we’ve talked about and worked on thus far. I’ll try to gather more usage stats about how users use menus from WordPress.com before our next office hours on Thursday.

        • Bob Gregor 10:17 pm on January 29, 2013 Permalink | Log in to Reply

          Thanks for those stats! Any chance you can find some stats on # of menu items?

          I think that will be very indicative of how we proceed with the UI.

          heres another view of the data you shared: http://cl.ly/image/143B0G3x2y3A definitely looks like a normal distribution.

          • Joey Kudish 2:47 pm on January 30, 2013 Permalink | Log in to Reply

            Yes, I’ll gather more stats by Thursday afternoon and will include # of menu items per menu in that stat as well. Stay tuned.

      • lessbloat 2:12 pm on January 30, 2013 Permalink | Log in to Reply

        Here’s an alternate flow that we may consider for when users have more than one menu. It ditches the management screen altogether in favor of a drop down.

        We tested using a drop down before (and it tested poorly), but I don’t think we put enough emphasis on it. It’s worth testing again, as long as it doesn’t overwhelm users (having so much on the same page).

        I also played around with adding check boxes under “use in”, as technically a user could use a single menu in multiple theme locations. I wonder if we could allow the user to select a widget placement from this screen as well via a check box. If they checked “Main Sidebar”, we’d auto-add a custom menu widget to the botom of the main sidebar widget area, and set the title of the custom menu widget as the name of the menu.

      • kwight 8:14 pm on January 30, 2013 Permalink | Log in to Reply

        Do we even need the Optional Settings part in the 0 menus layout, as that’s default behaviour anyways?

        Also, +1 for your handling of long menus in plugin territory.

    • kwight 8:11 pm on January 30, 2013 Permalink | Log in to Reply

      +1 for the Dropdown. I expect it would test better in this format, as it’s distinguishable from the other side metaboxes (by, um, not being on the side), unlike the current layout.

    • Bob Gregor 9:17 pm on January 30, 2013 Permalink | Log in to Reply

      part of the problem with the discussion is that there is a large variety of use cases. Here is a visual: http://cl.ly/image/3t0i3g2Y1G0y

      The # of menus data shows the right column to be the typical use case. # of items data is TBD

    • Helen Hou-Sandi 9:25 pm on January 30, 2013 Permalink | Log in to Reply

      As much of a problem as theme locations are, I don’t think moving the assignment into the editing of a given menu is the solution. We are then adding a problem of what happens if multiple menus are assigned to the same location, because it then becomes possible to do so.

      Have some other thoughts I need to chew on. Will comment again when I have sentences :)

      • lessbloat 3:37 am on January 31, 2013 Permalink | Log in to Reply

        I had two thoughts here. If a theme location currently has a menu assigned to it, we could :

        1) append the name of that menu (perhaps at #999), something like:

        and/or…

        2) onclick trigger a JS confirmation modal that says something to the effect of, “Are you sure you want to change your primary theme location from “Primary Menu” to “Main Navigation”?”.

    • Aaron D. Campbell 10:41 pm on January 30, 2013 Permalink | Log in to Reply

      There was plenty of discussion at the beginning of dev chat: https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2013-01-30&sort=asc#m543523

      It seems like http://f.cl.ly/items/3y2I0T1q2u3d3G3O0X1h/menus-multiple-select.png is pretty close and worth testing, with the one concern being the settings where a menu is assigned to a location.

    • Robert Chapin (miqrogroove) 10:59 pm on January 30, 2013 Permalink | Log in to Reply

      It’s still difficult to add tags to a menu. I tend to fall back on making a list of custom URLs when I can’t find things. It’s usually easier and faster too.

      Assigning menus is definitely broken. Every time I activate a theme on a new site it looks messed up. There should be menus assigned by default when assignments are missing.

      • Aaron D. Campbell 11:13 pm on January 30, 2013 Permalink | Log in to Reply

        Go to Screen Options, check the “tags” box, and then add them like you add anything else (check boxes on left and use “Add to Menu” button).

  • lessbloat 7:12 pm on January 23, 2013 Permalink
    Tags: , menus   

    For tomorrows “Menu” office hours I only have one agenda item: To figure out where we’re headed with menus in 3.6.

    (More …)

     
    • Devin Reams 7:37 pm on January 23, 2013 Permalink | Log in to Reply

      I like your concept.

      While it does require more screens to manage a menu (find the menu from the list, then click to edit it), I think simplifying and making the views granular is ideal:

      1. See all menus (then go edit them)
      2. Edit a menu’s contents
      3. Assign a menu to a theme location

      Some bloggers may only have one menu and this is overkill (just like those with one sidebar) but, many more complex sites may have dozens or a hundred menus, theme locations, etc. A question: what is harder and less flexible to satisfy all these possible use-cases?

      I also think a simpler, granular interface for each action may allow for better long-term goals: new enhancements, making it mobile/responsive friendly, etc.

    • Maor Chasen 8:58 pm on January 23, 2013 Permalink | Log in to Reply

      I just love the 2nd approach. Especially liking the theme customizer integration. Though, I have never seen an internal use of breadcrumbs within the dashboard. It just seems out of place.

    • mssbee 2:19 am on January 24, 2013 Permalink | Log in to Reply

      I like the first time menu screen. I am not a huge fan of more windows to open to get to what I want. Seems this whole project started from the thought that current menu screen is too difficult and even adding a home link is a challenge. I agree with Devin that the average user would probably have only one menu, as this might be overkill. Simple to me is simple interface that is intuitive that doesn’t take multiple clicks to get to.

    • Cliff Seal 2:35 pm on January 24, 2013 Permalink | Log in to Reply

      I think the flow of #2 would be most scalable and easiest for first-time menu creators to do what they want—but, can we incorporate the accordion-looking ‘Add Items…’ menu from the Nacin concept? I think all the individual CPT boxes, expanded automatically, become hard to locate at a glance.

    • iamronen 3:29 pm on January 24, 2013 Permalink | Log in to Reply

      I think that all three designs fail to address a core issue in the menu-editing screen. The left side that contains all the visual containers with sources of items to populate the menus is unpleasant to use when there is lots to choose from (many pages, posts, categories … not to mention websites with custom post-types … which create even more boxes).

      I’ve tried in the past to describe the problem in more detail here: http://www.odharma.com/2010/07/review-of-wordpress-menus-user-interface/

      The problem is (in my opinion) so severe that you would be hard-pressed to even draw a mockup that properly reflects the problem.

      This discussion started in a TRAC ticket where I mentioned a few more benefits from a modified design:
      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).

      • lessbloat 2:22 pm on January 25, 2013 Permalink | Log in to Reply

        I think that all three designs fail to address a core issue in the menu-editing screen. The left side that contains all the visual containers with sources of items to populate the menus is unpleasant to use when there is lots to choose from (many pages, posts, categories … not to mention websites with custom post-types … which create even more boxes).

        I agree, in that it does suck to have to scroll down to get to additional menu item options. Let’s see if we can figure out a way to improve this.

        The problem is (in my opinion) so severe that you would be hard-pressed to even draw a mockup that properly reflects the problem.

        That indeed sounds like a severe problem. ;-)

    • Robert Chapin (miqrogroove) 4:53 pm on January 24, 2013 Permalink | Log in to Reply

      So far none of these address the issue of adding Tags and Posts to menus.

      As for the screen layouts, I think two are appropriate considering there isn’t easy tabbing between menus.

    • lessbloat 2:14 pm on January 25, 2013 Permalink | Log in to Reply

      Office Hours Notes

      • See logs for full transcript.
      • We talked through likes & concerns for both options 1 & 2 above.
      • In the end we agreed to push forward with option 1.

      Next Steps

      • I plan to spend today working through all of the option 1 concerns (that we covered in office hours), and I’ll come up with another proposal for a mockup to move forward with (which I’ll post to this thread for review).
      • After that we’ll get a prototype hacked together, we’ll push a few cycles of user tests through it, and see how it performs.

      Ideas, mock ups, concerns, comments, criticisms are all welcome. :-)

    • lessbloat 2:03 am on January 26, 2013 Permalink | Log in to Reply

      Here are some updated mockups based on our discussion Thursday.

      One Menu

      This is all the vast majority of users would see:

      Multiple Menus

      Custom Menu Widget

      Switching Themes

      Adding A New Menu

      Let me know what you think. I tried to cover all of the concerns mentioned in the meeting on Thursday.

      • Drew Jaynes (DrewAPicture) 2:33 am on January 26, 2013 Permalink | Log in to Reply

        These are great! Looking through these, I have a couple of concerns:

        • “Copy items from existing menu” is interesting, but will we be able to maintain the hierarchy when the items are copied over?
        • With “Switching Themes”, it isn’t immediately clear what the process is to “reassign” a menu to a theme location (the current workflow). After a moment, I realized you would “Copy items from existing menu” via “Other menus” but we should provide some kind of contextual help for that. Maybe in the empty menu space?
        • We’ll need to be careful of not assuming too much about users, especially in terms of this “editing one menu at a time” mentality with the surrounding controls.
        • Would “unattached” menus live under “Other Menus”, or is that strictly for theme switching?
      • iamronen 6:28 am on January 26, 2013 Permalink | Log in to Reply

        well done.

        I would consider better balance between the two halves of the screen. There seems to be a lot of potential dead space on the right (menu side) and a lot of crunched up stuff on the left (things to put in menu). I would try either 50-50 or even 60-40.

      • Joey Kudish 8:01 am on January 26, 2013 Permalink | Log in to Reply

        Nice work. I really like the updated direction! A few comments:

        • I agree with Drew regarding switching themes, what happens then?
        • What happens if your theme supports several menu locations, it’s not quite clear to me from the mockups how it is that you assign menus to theme locations anymore.
        • Considering how little real estate the “add menu” button takes up and how valuable it might be to some users (especially those are now used to the current workflow) I am not convinced that hiding it by default is a great way to go about it. Could this be tested with existing users?
      • lessbloat 2:26 pm on January 26, 2013 Permalink | Log in to Reply

        So, my worry after working through all of these mockups is that by trying to be overly simplistic, we’re actually increasing complexity. :-(

        Have a peek through each of the mockups above, and I think you’ll see the same thing.

        Things I like

        • I really like the use of vertical tabs instead of meta boxes.
        • I like that for the majority of users they can jump right into building their menu, and that it is already assigned to a theme location.

        My concerns

        • The “Select a Menu” portion on the left hand side seems out of place to me. It doesn’t fit with the other two accordion options (add items, copy items). If a user is required to select from multiple menus, I still feel fairly strongly that we need to separate the “manage” functionality from “add/edit” functionality, otherwise there is just too much to take in on that single screen.
        • The concept of copying menu items from one menu to another works from a technical standpoint, but it seems overly complex.
        • To think that someone who just switched their theme will know to copy their menu items in order to bring their menu items over from their other theme is asking too much. Even if we could provide contextual help, it seems way more confusing than the way it is now (choose a menu for each theme location and click save).
        • I feel like this approach over complicates widget menu creation as well. The old way of adding a title, and selecting a menu seems like an easier flow to grok than forcing users to make a choice between creating a menu or selecting an existing one, and then switching contexts from widgets to menus and then back to widgets again in the same flow.
        • The concept of having “Menus in your theme”, and “other menus” under “Select a menu”, complicates things. It’s hard to tell the difference between the two. The user will wonder why they cannot delete the “menus in your theme” menus, but they can delete the “other menus”.
        • What happens if a user switches themes a dozen times (trying to find the right one). They’d come to menus and find at least a dozen menus from all the previous themes they tried (since the idea here is to pre-build all theme location menus for each theme). Not to mention, we’d have to write the code that pre-creates all theme location menus each time you switch a theme.
        • While, hiding the “add menu” button seemingly simplifies things for new users, I don’t think it will work. Existing users will wonder where it went. If we leave it there, new users will no doubt get lost trying to add a new menu (either following one of hundreds of existing menus tutorials on the web, or by following instructions in a book, or by just stumbling onto it), when in fact their theme locations menus are already created.
        • If we add icons for each menu item option (in the vertical tabs), what happens when you add a CPT? Would they have to add their own icon? That sounds too complex. I don’t think we can use icons here.

        In contrast

        Out of the last 3 users we tested on option 2 (see results here and here), one of them completed all of the tasks flawlessly, and the other two only stumbled on a single step (selecting a primary menu).

        After the meeting on Thursday, I was fairly confident that we could make option 1 work. After working though all of the edge cases, I’m now much less confident.

        My proposal

        What if instead of diving head first into option 1, we instead chose to keep iterating on option 2:

        • We could spend our energy iterating on the one piece that still seems broken (selecting a theme location), instead of trying to smooth out all of the complexities that come with option 1.
        • We could simplify things for users with just one menu. If they only have one menu, we could remove the tabs and the manage screen, and take them right to editing that one menu.
        • We could bring the new vertical tab menu items selection concept over (I much prefer that to meta boxes, and having to scroll if you have lots of them).

        That’s my proposal, what do you think?

        • iamronen 5:59 pm on January 26, 2013 Permalink | Log in to Reply

          I think that a lot of the complexity you mentioned is rooted in what may be a false notion that menus are a part of the site “appearance” – that they belong to a theme.

          A different view would be that menus are another means of organizing “things” in my website (kind of like categories are used to organize posts).

          Though the primary purpose of menus is for navigating in the site (indeed a thing of appearance) that is not what governs their content.

          My intuition (I have no data to back this up) tells me that most people (who have one menu) when they change themes, do not change menus. I can definitely say that in almost all of the websites that I’ve created that have had many menus – that the menus should have stayed when themes switched (the fact that they don’t has forced me to do twisted things in my theme management practices).

          I believe that the fact that menus are a part of themes is a behavior that has evolved from their technical development, not from what they are and do. Their underlying story is just now surfacing.

          If you free menus to be another organizational entity regardless of appearance (though I realize this may be way beyond the scope of 3.6) then they most absolutely should be split into the common WordPress paradigm of managed list and single-item edit.

          I also believe that presented in this way, people will more quickly understand that they can create more menus (since they know this visual paradigm intimately from working with posts and pages).

          This way:

          • menus will be more straightforward and intuitive.
          • there won’t be a need for complex behaviors such as “copying menus” which will only create useless copies of the same thing.
          • there won’t be a need for a unique and complicated interaction and relationship between menus and widgets (the current widget is fine and will be better understood once menus become more clear)

          The only apsect of menus that I can think of that should remain as part of the appearance/theme configuration would be theme locations.

          I realize this may sound radical … but I believe that the complexities you listed are telling us that the underlying story of menus has not been properly addressed and it needs to be re-examined if a good solution is to be found.

          • lessbloat 3:22 pm on January 28, 2013 Permalink | Log in to Reply

            I guess I’m unclear, where exactly are you proposing that menus should go?

            • iamronen 4:08 am on January 29, 2013 Permalink

              I can’t think of a good answer for that (though I may have inklings of a better question).

              The two options I currently see are (1) inside the “appearace” menu or (2) a separate admin-section. For now, I am indifferent to them.

              In either case, I think it would be better to have them conform to the dominant UI pattern that includes a list of Menus (where the description can be a textual preview of the menu contents) from which you can choose to edit a menu.

    • paaljoachim 12:48 pm on January 28, 2013 Permalink | Log in to Reply

      I looked at the above wireframes and created some of my own to give inspiration to others. Psd and jpg files are included in this link for anyone to continue testing out things.

      https://www.dropbox.com/sh/4vpue85dkzsrk0q/6FtXDun3QD

      Have a great day!

    • Bob Gregor 9:56 pm on January 29, 2013 Permalink | Log in to Reply

      One thought regarding copying menu items – that should be a dragabble / droppable interface. Much lessbloat (pun intended) perhaps drag / drop w/ a featured pointer?

      I like the two tab iteration better – one tab for doing the majority of the work – editing and building menus, and another tab for changing assigning / them. The non-metabox menu builder is a huge improvement, but I don’t like seeing the unrelated options of select a menu and copy menu items. Those feel out of place.

      In any case – I definitely agree we need to keep iterating. Great work lessbloat! The mockups are looking great!

  • lessbloat 1:13 pm on January 21, 2013 Permalink
    Tags: , menus   

    Menus discussion today 

    I’d like to hold our first menus IRC discussion today at 21:00 UTC (4:00pm EST, 1:00pm PST) in #wordpress-dev.

    Here’s a reminder of more or less where we’re at: http://make.wordpress.org/core/2013/01/16/heres-a-quick-update-on-the-3-6-menu/

    In addition to talking about the feature, we’ll figure out a good time to hold all other bi-weekly meetings. Thanks!

     
    • Alex King 3:13 pm on January 21, 2013 Permalink | Log in to Reply

      I will be on a plane and unable to attend the IRC meeting, but wanted to throw in my request for being able to filter in new “types” of menu items and fully override the output of any particular menu item. Super-useful for mega-menus, etc.

      The change to 2 screens sounds like it will address to “too many menus for the UX design” – awesome!

    • lessbloat 4:52 pm on January 21, 2013 Permalink | Log in to Reply

      Thanks Alex,

      wanted to throw in my request for being able to filter in new “types” of menu items

      Mind explaining that one a bit more, and I’ll bring that up in the meeting.

      wanted to throw in my request for being able to…fully override the output of any particular menu item

      I was thinking about this over the weekend, and I agree. I think this will go a long way towards making edge cases (collapsable trees, bulk menu item actions, etc…) easily extensible via plugins. My goal is to keep this clean, lean, and mean for the majority of users, but to also make menus easy to extend.

    • lessbloat 8:54 pm on January 21, 2013 Permalink | Log in to Reply

      Here’s the rough agenda I’d like to follow today if possible:

      • Welcome
      • Time for office hours
      • Here’s where we’re at: http://core.trac.wordpress.org/ticket/23119#comment:131
      • There was some concern in the last dev chat that the manage screen is too heavy?
      • 2 files or 1?
      • Common links name: “Handy links”, “Useful Links”, “Helpful Links”, “Quick Links”
      • Alex King’s first point: being able to fully override the output of any particular menu item
      • Theme locations
      • Linking to widgets
      • Alex King’s second point: being able to filter in new “types” of menu items (not 100% sure what he meant with this one)
      • Anything else?
    • lessbloat 4:45 pm on January 22, 2013 Permalink | Log in to Reply

      Here’s a recap of what we covered:

      • Office hours for menus in 3.6
      • Nacins menu workflow concept
      • “Common links” meta box

      Office hours for menus in 3.6

      We’ll plan on having office hours Mon & Thu at 21:00 UTC (4:00pm EST, 1:00pm PST) in #wordpress-dev

      If there’s an agenda (there likely will be for the next couple), I’ll post it here on the make/core P2. Otherwise feel free to come with questions/thoughts.

      Nacins menu workflow concept

      Nacin shared the following observations:

      • The current UI is too advanced, and any workflow improvements should make it more simple for users.
      • The most common use case is having one menu.
      • The vast majority of menus are used in theme locations and widgets. We should tailor around those two use cases.
      • The current workflow: A) create a menu from scratch, and then B) assign it to either a theme location, or a widget can lead to confusion, and is quite possibly overly complex.

      And proposed a rough concept along the lines of:

      • With the custom menu widget, you’d: 1) add a custom menu widget to the sidebar 2) click a “Edit this menu” link/button which takes you to a screen where you’d edit that menu. This would likely take you to nav-menus.php?menu=that-menu-id. If the custom menu widget is newly added, it would take you to the “add new menu” screen.
      • With theme locations, instead of selecting from a drop down of menus that you’ve created, each theme location would just have a link to edit that menu. You’d 1) Click the edit link under the theme location you’d like to edit, 2) Make changes to that pre-existing menu, 3) click save, and be done.
      • We’d no longer need to display a list of menus you have, we’d just display a list of theme locations. Widget menus are represented in the widgets section, so they don’t need to be listed anywhere.

      Edge cases brought up (which we’d have to consider to make this work):

      • While theme locations and widgets cover the vast majority of use cases for menus, you can use them elsewhere. wp_nav_menu() accepts ID, slug, or name of a menu. As such, we’d still need to be able to provide a way for users to add menus outside of theme locations and widgets. How would we display these additional menus?
      • What happens to my predefined theme location menus when I switch themes to a theme which has a completely different set of theme locations? How would that work in the UI?

      “Common links” meta box

      We proposed “Common Links” meta box in 23119.14.diff. Currently it defaults to showing a “home” link, and a “log in” link. Both of which are relatively hard to add to a menu.

      The idea is to:

      • Move the ‘Home’ link out of the Pages
      • Make it easy to add a link to the login form (which many users have trouble with)
      • Make these links easily discoverable
      • Provide a filter for plugins to add/remove links to this “other” metabox

      I had hoped to settle on whether we should keep this new meta box, and if so, what we should call it. Both are still up in the air.

      Things to think about before our next office hours

      1) How can we make Nacins concept work?
      2) Should we keep the new custom links meta box? If so, what should we call it?

      • lessbloat 6:27 pm on January 23, 2013 Permalink | Log in to Reply

        I mocked up my interpretation of Nacins concept:

        A couple notes:

        • My thought was that we could add another option in screen options to show/hide the “add menu” button on the page (in the normal spot next to the header). It would be hidden by default. This way, advanced users can still add menus for the edge cases mentioned above (when added, they’ll also show up in the “Select a menu” area), but the majority of users will no longer have to deal with the complexity of adding a menu and then assigning it to a theme location.
        • When you switch themes, any menu which was assigned to a default menu, would just become an unassigned menu. You could then click to edit the unassigned menu, and then assign it to a theme location in the new theme (through a drop down or something – perhaps at the bottom of the right column). Widget menus would just transfer over.
        • Upon adding a custom menu widget, you’d see this:

        Or something similar, which would take you back to nav-menus.php.

        What do you think? Could this approach work? If not, why?

        p.s. Please don’t focus on the aesthetic of the design at this point. This is just a rough mockup. If the concept works, we can focus on improving the way it looks next.

        • Aaron D. Campbell 6:50 pm on January 23, 2013 Permalink | Log in to Reply

          My first thoughts:

          The things I like:

          • I really like the way this handles new widgets.
          • I like that it feels very light weight.

          The questions/concerns:

          • I’d love to see how you’ll handle adding existing menus as a widget. For example, if you change themes and you want one of those unassigned menus to be used as a widget or if you create the menu before you add the widget.
          • Widgets save immediately, so we need to make sure that a new widget with an empty menu has no output. We also need to make sure that updating a menu used in a widget clears any cache associated with the widget.
          • If you have a decent number of menus, even just 10, then you really start pushing down that left column of items to add.
    • Robert Chapin (miqrogroove) 4:49 pm on January 24, 2013 Permalink | Log in to Reply

      A common problem with this mockup and the 3.5 system is that there is no visual indication of where to find Tags, Posts, and other menu items that are missing by default.

  • lessbloat 8:32 pm on January 16, 2013 Permalink
    Tags: , menus   

    Here’s a quick update on the 3.6 menu changes we’ve been making:

    Last week we:

    • Merged the the UI into two screens. Now we have manage menus & add/edit menus.
    • Tested this new two screen approach. It went really well (we put two users through – videos are on the Make/UI P2).
    • Improved & simplified some copy
    • Added a new hookable “common links” meta box with “home” and “Log in” as the default links (both of which are fairly confusing to try and add to a menu otherwise).
    • Added keyboard accessibility for rearranging menu items

    What’s left:

    CODE

    • Break this out into two separate files 1) manage 2) add/edit (@jkudish is on this)
    • Code review everything (@jkudish volunteered)

    DOCS

    TESTING

    • Once the code items are complete, I’ll run another round of user tests (@lessbloat)
    • RTL testing
    • Browser compatibility testing
    • No JS testing

    If you’ve got some time, we’d love your help with testing the latest patch.

    Lastly:

    I’d love to hear all of your thoughts, concerns, criticisms. :-)

     
  • Aaron D. Campbell 1:07 am on January 8, 2013 Permalink
    Tags: , menus   

    WordPress 3.6: Menus 

    For menus we’re going to try to focus on some UI improvements. Menus work pretty well but users, especially the less-technical ones, are easily confused. We’ve seen them try to add menus without names because they see the “Create Menu” button before they see the menu name field, we’ve seen them add a bunch of menus instead of menu items because they’re unclear on the difference, etc, etc. The goal for the 3.6 cycle is to make menus a little more intuitive and user friendly.

    @markjaquith and I are excited to have @lessbloat leading this. Take a look at all the user testing that has already been happening over at #23119 and make sure you comment here if you’re interested in helping out!

     
  • Ryan Boren 1:40 pm on June 2, 2010 Permalink
    Tags: menus, ,   

    Justin has a nice theme developer oriented review of the nav menus.

    Ron talks about upgrading from MU to 3.0.

     
  • Jen Mylo 3:27 pm on April 8, 2010 Permalink
    Tags: menus   

    Updated Menu Wireframes. I’m still a little unclear on how some of the fields appear, but wanted to post this for Ptah’s reference. Can Filosofo give a status update at today’s dev chat on how the accessible version is coming along? (Or comment on this post if unable to attend dev chat today.)

     
    • Andrew Nacin 3:34 pm on April 8, 2010 Permalink | Log in to Reply

      Really liking the slide-down menu item settings, and the removal of thickbox from the mix.

    • Nathan Rice 3:40 pm on April 8, 2010 Permalink | Log in to Reply

      What is supposed to happen if you have more than 3 menus? Do the tabs stack? Is there going to be some sort of overflow mechanism?

      • Andrew Nacin 3:46 pm on April 8, 2010 Permalink | Log in to Reply

        It’s just a wireframe. More than 3 will fit I’m sure, though it’s a good question. I’d like to continue to see subsubsub links, though I’m not sure if the wireframes indicate a move away from that.

        • Jane Wells 3:53 pm on April 8, 2010 Permalink | Log in to Reply

          I was thinking there could be a tab before the + tab a la browser tabs (5 more menus) that drops down a list for people who have more than 4-5. Note in this wireframe I also have a narrowish menu column just because of a screenshot I started from. Would be wider IRL.

          When editing submenu item info, would expect the bar to grow into full width of top-level menu item, kind of like widgets expand for easier editing.

        • JohnONolan 8:36 pm on April 8, 2010 Permalink | Log in to Reply

          Great idea – I like that

    • Mo Jangda 6:11 pm on April 8, 2010 Permalink | Log in to Reply

      For new menu creation (on page 2), I assume that the left hand widgets will be hidden, or at least disabled?

    • Mo Jangda 7:05 pm on April 8, 2010 Permalink | Log in to Reply

      Not sure if this has been decided yet, but in “accessibility mode”, I’d recommend that Categories and Tabs Widgets default to “View All” and that the “Most Viewed” and “Search” are added by “progressively enhancing” the widget. (Sorry, that’s a lot of quotation marks.)

    • mikeschinkel 8:38 pm on April 8, 2010 Permalink | Log in to Reply

      JMTCW – I’d really like to see the Browse/Search boxes stay on the right, or at least have an option to move them there. My memory with UX studies are that putting things one has to frequently interact with closer to the scroll bar results in less required mouse movement. Of course I’m not expert, but my bias would be to have them stay on the right.

      • Jane Wells 2:54 pm on April 9, 2010 Permalink | Log in to Reply

        This was discussed at length in both the UI working group IRC chat and in the #wordpress-dev weekly dev chat before the decision was made over a week ago. Menus are not like creating posts, they are like using widgets to assemble sidebars. Having the available options on the left and the end result on the right is consistent with the widgets screen, as has been discussed several times before (including on this blog). In addition, mouse actions in relation to scrolling during usability testing were discussed, and contributed to the layout change. The meta boxes stay in one position, while the menu may get long, especially with submenus, and that is why the menu assembly should be closer to the scroll, since users usually won’t need to scroll unless the menu itself gets long and they want to reorder items. The decision was made and the initial wireframes with this layout were approved before beta1 over a week ago, and these were just a more detailed version for developer reference.

        • Xavier 4:56 pm on April 9, 2010 Permalink | Log in to Reply

          “This was discussed at length (…) over a week ago”
          “has been discussed several times before (including on this blog)”
          “were discussed”
          “The decision was made (…) over a week ago”

          Say no more! ;)
          I think Mike and I just missed (or plain forgot about) said discussions. Our bad!
          Keep on doing the good work, Jane :)

        • mikeschinkel 5:02 pm on April 9, 2010 Permalink | Log in to Reply

          @Xavier: Yes, she did seem to be beating us about the head and neck with it, no? ;-)

          I think it’s a preference thing. I personally don’t like the left-right Widget layout so using it as a justification rings hollow to me. I’d prefer an option given how easy it is to switch HTML layouts from left-to-right but I won’t belabor the point beyond this last comment.

        • Jane Wells 5:06 pm on April 9, 2010 Permalink | Log in to Reply

          @mikeschinkel: The fact you “personally don’t like” something rings hollow to me as a justification for changing a layout that was agreed upon by both the UI group and the lead developers (and core contributors in the dev chat). We try to avoid adding unnecessary options in WordPress. Hooks for plugins to do option-type things are almost always preferred, as has come up in a number of recent conversations.

        • mikeschinkel 5:12 pm on April 9, 2010 Permalink | Log in to Reply

          @Jane Sigh. All I said was it would be nice to have an option ( a hook *is* an option, btw), but forgive me for voicing my opinion. I’m getting the distinct opinion that those of us in the community are preferred to be seen but not heard.

        • Jane Wells 5:18 pm on April 9, 2010 Permalink | Log in to Reply

          @mikeschinkel. We use “option” to mean a choice in the UI, vs adding a hook for a plugin to do something. It is not true that the community should be seen but not heard; it *is* true that if choosing to participate as a contributing developer rather than a user (this blog is for active development, after all), then participating in the discussions when decisions are made rather than complaining about the outcomes after the fact would be more productive. Raising something after the fact is also fine; not everyone can make the dev chat, we know that. However, raising things after the fact should be done as a developer, not a regular user. Because no, it would not be appropriate for 20 million users to be giving feedback in the contributing developer communication channels. There are other places for user feedback.

        • Andrew Nacin 5:20 pm on April 9, 2010 Permalink | Log in to Reply

          Jane made most of my reply redundant. So I will only add that a plugin should be able to move things around with a little CSS.

        • mikeschinkel 5:20 pm on April 9, 2010 Permalink | Log in to Reply

          Fair point.

        • Peter Westwood 9:12 pm on April 9, 2010 Permalink | Log in to Reply

          I would be very surprised if a plugin can’t move things around with CSS – I suspect that the CSS will exist soon enough if it doesn’t already for one of the Right to Left translations.

    • Xavier 12:43 pm on April 9, 2010 Permalink | Log in to Reply

      This looks very slick, and a vast improvement over the current version.
      That being said, I’m seconding Mike’s suggestion to keep the boxes on the right side (just as the Edit Post screen has its box there).

  • Jen Mylo 4:33 pm on March 16, 2010 Permalink
    Tags: menus   

    I’m kind of thrown by what has turned up in menus since I looked at it two days ago. It appears that you can now add everything under the sun to a custom menu. The feature we talked about adding in 3.0 was to support adding pages, categories, and links. As v1 of the feature, I think it’s important we rein ourselves in here. Advanced menu stuff belongs in a plugin, not in core. It could be a core plugin, but having the default menu creator in v1 have that many options (post, page, link, tag, category, media file) is going too far and is outside the scope we all approved. We need a *basic* menu feature that plugins can build on; we should not put the whole kit and caboodle in core. If we want to put out a core plugin to add all the other stuff, I would support that, but for core I think we need to strip it back a little and focus on making it accessible.

     
    • Crago 4:36 pm on March 16, 2010 Permalink | Log in to Reply

      Terrible idea! Let the menu spread its menu-wings and fly!

    • scribu 5:03 pm on March 16, 2010 Permalink | Log in to Reply

      I agree that all we need in core, at least for 3.0 is page, category and link menu items.

    • Ryan 5:14 pm on March 16, 2010 Permalink | Log in to Reply

      A plugin to turn them on would be trivial. Perhaps we can add flags to the post type and taxonomy registration to enable showing them in the menu admin.

      • Nathan Rice 5:20 pm on March 16, 2010 Permalink | Log in to Reply

        I totally agree. A plugin to support custom post types (which are now a part of core, lest we forget) would be nonsense. However, a flag in the post type creation would be perfectly legitimate, and a much more elegant solution, IMO.

        Pulling out perfectly functional features seems like a bad move. It makes no sense.

      • Ryan 5:27 pm on March 16, 2010 Permalink | Log in to Reply

        I added a couple filters that will allow plugins to turn on other types and taxonomies. Since a registration flag could become obsolete in the future, I thought some dedicated filters would be better.

    • Peter 6:03 pm on March 16, 2010 Permalink | Log in to Reply

      What is the point of removing the capacity to have a menu of tags, when doing so neither increases nor decreases accessibility, nor does it affect the present subject of concentration.
      Having tags as menus actually INCREASES accessibility, because nav menus are more controllable, when it comes to accessibility features, than , for example, tag clouds.

      Secondly, post, page, link, tag, category, media file does not equal kit and kaboodle. It adds three extra types of links.

      I am concerned that removing elements from something so important, and for which people have waited a long time, will be done without logical reason. And, respectfully, I would say that Jane’s post contains no logical reason, just an appeal to restraint – perhaps on moral grounds?

    • Peter Westwood 6:22 pm on March 16, 2010 Permalink | Log in to Reply

      We do need to focus on getting the core functionality we agreed on in the dev chats working fully before we add all these extra menu item types and ideally we should only support for 3.0 the core types we discussed.

      I have been receiving personal reports that the current functionality is still very alpha in quaility and effort would be best expounded on making the core functionality rock solid than adding loads of extra menu item types.

    • ocean90 6:24 pm on March 16, 2010 Permalink | Log in to Reply

      I like the last update really. I show it some of my friends and they really like this feature.
      I think the Custom Menu is THE eyecatcher of 3.0 and so we should make it as # nice as possible. So that every user can make his own custom menu without searching any plugins to add some things again, then I don’t need the menu and add directly a plugin which can all of this.
      It should be easy.

      But I like the idea of ryan. +1.
      Eventuelly we can add screen options and add checkboxes for the ‘widgets’ and hide for example media on default.

    • Rich Pedley 6:37 pm on March 16, 2010 Permalink | Log in to Reply

      Surely the default menus system should actually include pages/posts/categories/links/tags because they are bulk standard to a WP install? So to me the current set has one extra that should be removed – that of adding a custom link. That one should IMO be handled via a plugin.

      Also please accept my apologies, have been trying to find time for the 2 of us, esmi(from the WP forums) and myself to look at the accessibility side of things and failing miserably as other projects get in the way.

    • Carl Hancock 6:45 pm on March 16, 2010 Permalink | Log in to Reply

      If you have the ability to add categories to your nav why not include tags? They are both taxonomy. I agree Media is taking things a bit too far and I don’t even use the Link functionality so I don’t find that very useful. But I think an Add Tag menu option would be extremely useful as part of the core.

    • Carl Hancock 6:47 pm on March 16, 2010 Permalink | Log in to Reply

      Forgot to mention +1 for a flag on custom post types to add a menu option in the menu builder when you add a custom post type. It seems that would round out the custom post type capabilities of 3.0 and make the Menus actually usable with custom post types. As they are now yes you could do custom post types, but your nav would have to be all manually done using links which would be a pain.

      • Idealien 8:14 pm on March 16, 2010 Permalink | Log in to Reply

        I agree. While 3.0 might happen to numerically be “just the next release” from 2.9, the opportunity to bring a combination of significant new features to core (UI for custom post types and dynamic built menus that support them) is worth shooting for with this symbolic major version release.

    • Peter 6:49 pm on March 16, 2010 Permalink | Log in to Reply

      I think too that removing tags is, to be frank, absurd. It assumes that, in the use of wordpress, categories occupy a position of greater importance when navigating a blog, than tags. And that is not true. Adding media files is, I agree, unnecessary.

    • Ryan 7:10 pm on March 16, 2010 Permalink | Log in to Reply

      With just Pages, Categories, and Custom Links the screen is already scrolling, especially once you click View All. If we add more things we have to solve that.

      Categories are the correct taxonomy for menus. Almost all themes use Categories for menu purposes. Using tags in the menus is a bit of a misuse, technically. Of course, everyone has their favorite means of using taxonomy, with many not using Categories at all. I personally would like to have Tags present, but the underlying UI issue would have to be addressed. The scrolling makes for very bad UI. You can’t the see menu when you click Add to Menu. After clicking, all you see is the selections in the checklist clear. There is absolutely no useful feedback when you are scrolled.

      Keep in mind that Custom Links allow linking to anything. Tag menu items can be added as custom links.

      • Carl Hancock 7:15 pm on March 16, 2010 Permalink | Log in to Reply

        Make the add menu boxes collapsable like sidebars in the Widget editor. Then just open the first one. A user can expand/collapse the others as needed. This would leave plenty of room to include Tags, which are core to WordPress and users ARE going to want to add tags to their menus. Sure you can add anything you want with the Custom Links functionality, but shouldn’t it at least cover the core WordPress features of posts, pages, categories and tags and then leave the rest to Custom Links or plugins?

        • Ryan 7:29 pm on March 16, 2010 Permalink | Log in to Reply

          They are collapse-able. They can also be made hide-able. It’s still bad UI once you show those things though. If we allow displaying those things we need to have a UI that can handle them.

          Tags seem to be the main point of contention. I would like to have them in there, but we need to figure a way to eliminate the scrolling. Moving Create Menu and Menu Settings out of the sidebar might help. “Delete Menu” and “Save Menu” could move back below the menu. Menu name editing could be exposed on the menu bar on hover like we do with the dashboard boxes.

        • Carl Hancock 7:39 pm on March 16, 2010 Permalink | Log in to Reply

          Remove menu settings. Move the menu title to above the menu itself just like where you edit a Post/Page Title in the post editor. Then put the save link below the menu again instead of on the right sidebar.

          Remove the “Create Menu” box. Place an “Add New” button to the right of the Menus page title that then creates a new menu… name it and save it. Make the name required.

          That frees up space for Tags on the right side by eliminating two of the existing boxes. At that point the only thing that would appear on the right side are the “Add…” toolboxes. Leaving space for Tags and hooks to allow additional boxes to be added (Custom Post Types, etc.).

      • Nathan Rice 7:33 pm on March 16, 2010 Permalink | Log in to Reply

        What screen resolution is assumed for UI purposes? On my netbook, I’d be willing to bet there’s going to be scrolling no matter what you guys do :-) But I don’t necessarily think that’s a problem, since netbooks aren’t the norm.

    • Carl Hancock 7:55 pm on March 16, 2010 Permalink | Log in to Reply

      I put together a quick mock up that shows what I described in a comment above as far as re-arranging stuff to free up space on the right sidebar so that it is strictly the “Add” toolbox area. It’s obviously just thrown together quickly.

      View it here:

      http://www.twitpic.com/18zl8j

      • The Menu name is moved into the content area similar to how you edit the Post/Page name.
      • The Add New link/button is moved to the standard location next to the page header.
      • With those 2 boxes removed from the right side, the Save button is moved to the content area and left aligned. Why left aligned? Because when the save button appears in the content area it is always left aligned (see Add Categories, Add Tags, Theme/Plugin Editor, Settings pages, etc.).
      • Carl Hancock 7:56 pm on March 16, 2010 Permalink | Log in to Reply

        Forgot to mention, the “Add Existing…” seems redundant. It could probably just be “Add Page”, “Add Category”, etc. Add Custom Link doesn’t use that terminology despite the fact whatever you are linking to obviously already exists.

        • Idealien 8:01 pm on March 16, 2010 Permalink | Log in to Reply

          I agree “Add Existing…” is redundant, but “Add Category” gives the impression it (might) add a new category to the db. What about “Add [Item] to menu” as the title and then a consistent ‘Add’ button across all of the entry boxes?

      • Ryan 7:57 pm on March 16, 2010 Permalink | Log in to Reply

        That looks good to me, regardless of the scrolling issue. I like having the sidebar be exclusively for adding menu items. I’m just the code monkey though, and will leave further discussion to you UI/UX folks. :-)

      • Mark McWilliams 8:10 pm on March 16, 2010 Permalink | Log in to Reply

        I was thinking, do we really need the ability to alter the Menu Name? Am I not right in thinking that a theme author could register a menu in the functions.php file to work with their particular theme? – If the user ended up changing that, wouldn’t it mess with the theme? (Maybe unrelated yes, but while I’m here!)

        • Carl Hancock 8:27 pm on March 16, 2010 Permalink | Log in to Reply

          Not having a way to edit the name and having it basically set in stone would be obnoxious from a usability standpoint IMO. Can menus be called via id instead of name on the front end? If so call the menu by the id and then it doesn’t matter what the name is.

        • Mark McWilliams 1:32 am on March 17, 2010 Permalink | Log in to Reply

          OK I’ve obviously not tested it out, but I’d take a guess and say that registering a menu in the functions.php file isn’t going to work well just by giving it an ID…? Yes they can be called on the front end via an ID, maybe it’s just a personal thing!

          On the other hand though, to alter a Custom Taxonomy or a Custom Post Type, we’d have to alter the plugin or functions.php file itself, kind of a swings and roundabout situation here! ;)

    • djeckhart 8:25 pm on March 16, 2010 Permalink | Log in to Reply

      Agree that “Media Files” could go. The rest, particularly support for post types, is/should be core functionality.

    • ceenz 11:14 pm on March 16, 2010 Permalink | Log in to Reply

      All the ‘add existing…’ boxes on the right side of the menu admin page make no sense. Why not just have one for existing items and have a drop down for the type you want to add.

      EG:
      [Add Existing Content Title]
      Type: [Drop Down of Types Available]
      [Search Box] [Search Button]
      [View All Link]

    • Ptah Dunbar 7:56 am on March 17, 2010 Permalink | Log in to Reply

      @jane, I sent you an email re: menus last week or so asking for UI advice, but haven’t heard back so I just went with what felt right. Here’s some of my reasoning.

      The save/delete button being at the button isn’t the best location as users will have to scroll all the way down to save when their menus become long. So I added them to the sidebar along with the ability to edit the name.

      The ability to support any post type/taxonomy was not me drifting away from bug fixing to adding features, but it was actually an added benefit while I was cleaning up the menu codebase to make the menu item types more abstract so plugin authors can add their own stuff. Based on the way the menu system works, adding additional menu item types would require the plugin author to create their own meta box along with the some js which is not WP standard. Before the last patch, they couldn’t even do that. So I added support for all types under the hood so I don’t mind the UI being limited to just pages and cats. The code is their to support any type so plugin authors only need to modify a filter and boom, it’s there.

      Also, instead of the filters, a better approach would be to just enable the pages and cats metaboxes to be ON by default while the other types are hidden and just a checkbox away in the screen options. win win?

      Right now, I’m focusing on fixing the saving/positioning bugs and making the core functionality solid. All my patches up until now were working towards this. But bug fighting is a combination of js and cross browser issues so I just have to do more testing with different browsers and such.

      Menus needs a combination of UI and bug fixing work. I can do the bug fixing part, but I’d very much like to get some explicit direction from you regarding the UI and what needs to happen. I’m just a code wrangler with aspiring UX/UI skills :)

    • Frank 12:01 pm on March 17, 2010 Permalink | Log in to Reply

      Thanks Jane,
      please give WP not s much features, please more features in core-plugins (my benefit to Core plugins). To many features in a new version ,in the core, this is a ko for the users, not realy good for WordPress.

    • Stephen R 12:23 pm on March 17, 2010 Permalink | Log in to Reply

      As a matter of general principle, I’m with Jane on this one. Best to show a bit of restraint than to cram the UI on the first iteration. You can always add later if the need is there, but it’s troublesome to remove things later…..

    • dd32 12:31 pm on March 17, 2010 Permalink | Log in to Reply

      I’d just like to back up the choices made during the development of the menu’s a bit.

      While Custom Post type and Custom taxonomy was not an agree’d part of the spec, Leaving them out is actually an increased amount of work, leaving them out doesnt make the functionality any easier to implement.

      The obvious reason to this is, that Posts and Pages are just post_types, Categories are just Taxonomies. Since WordPress offers such decent API’s, it makes it possible to use the Internal API’s and mearly create a generic post_type and generic Taxonomy functionality, and loop over it.

      Since this post has been written, I’m pretty certain that the functionality was extended further, so that post_type’s and custom taxonomies have to register a flag during registration to allow them to appear in the menu editor. (A Screen option would’ve been another option there, but not all objects are menu-usable anyway)

      For everyone else just stumbling across this post now, The menu editor as of this comment, only displays “Custom Links”, Pages and Categories by default.

    • ceenz 1:48 am on March 18, 2010 Permalink | Log in to Reply

      WOW I AM HORRIFIED AT HOW MENUS HAS EVOLVED IN WP.

      I have just been digging into the code for menu creating and management for the last 4 hours and cannot believe how convoluted, complicated and WAY over the top it all is. I cannot understand why simple menus require to be linked in with taxonomy, taxonomy relationships etc. I then looked at the number of data options stored in the wp_options DB totally ridiculous, there’s something like 15 different entries just for nav_menus.

      THE WHOLE MENU CREATION / ADMIN coding needs to be really looked at again with some type of DIRECTION and PATH mapped out. It is really a MESS, with just code piled up on top of each other.

      There needs only to be one DB entry for nav_menus and one for nav_menu_items in WP_options thats it. None of this taxonomy linking BS, none of the over the top nav_menu options currently in place.

      Each instance of nav_menu should have an id, name, array for items and array for options.
      Each nav_menu_item should have an id, name, link, type, and array for options.

      That is seriously all that is required.

      All the BS surrounding custom post types different taxonomy (eg tag, categories) can be handled through an extend-able nav_menu class based on the nav_menu_item type and store the unique options for the type in the nav_menu_item options array.

      I am really sorry but the whole situation is making me really angry.

      • Peter Westwood 8:39 pm on March 25, 2010 Permalink | Log in to Reply

        I’m not sure how storing everything is big serialised arrays really helps.

        There are a number of issues with doing it that way including the fragility of the php serialisation format with International characters in the strings and the issues around caching and interactivity if more than one person edits a menu structure which make it a sub optimal solution.

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel