WordPress.org

lessbloat 7:12 pm on January 23, 2013 Permalink
Tags: 3.6 ( 63 ), menus ( 12 )   

• 

  Devin Reams 7:37 pm on January 23, 2013 Permalink

  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

  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

  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

  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

  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

    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

  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.

  • 

    Andrew Nacin 5:02 pm on January 24, 2013 Permalink

    Look in screen options.

• 

  lessbloat 2:14 pm on January 25, 2013 Permalink

  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

  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

    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

    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

    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

    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

      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

        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

  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

  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!