Some Not Happy With Flyout Menus

Flyout MenusIn my short look at WordPress 3.3 Beta 1, I highlighted the fact that all menus were going to receive the Flyout treatment. The ability to vertically expand or collapse menus will be disappearing in favor of the flyout animation. Personally, I like the feature as I now get to see all of the menu items without having to click a button. However, many others have voiced their discontent with this User Interface change. In fact, there is a thread on the WordPress.org support forums that is nearing 50 posts specifically dealing with this issue.

Even though I like flyouts, I don’t have any problem with the way menus work in WordPress 3.2. In fact, it was the best of both worlds. I typically use the Icons only approach which has the flyouts while always having the option to see the full menu with the ability to vertically expand or collapse. In the newest instance, that choice has been taken away. This response by Jonschlinkert has some interesting questions that I think would be good to have answered from the WordPress UI Team.

Who was asking you to remove the expand/collapse feature? Can you point us to that request and the support for it? In other words, why is the designer “fixing” something that wasn’t broken?

If you’re interested in seeing how the feature evolved, look at the log for ticket #18382. For the curious, here is a short list of statements made in the WordPress Development Channel from May 31st 2011 to October 11th 2011, talking about the flyout menus. Nothing really exciting to read with the exception of Otto42s comment on September 19th.

Otto42 – they make everything take like 3 times longer to find. i used to just scroll the page and go right to the menu i want.. now it’s a matter of hunting and searching and checking the f-ing flyout menus

If Flyout menus get past beta and are in the final release, that is when we will be able to measure the success or failure of the change. If a major revolt happens, it’s not like reverting the change will be hard and it could come in a follow up point release. At the end of the day though, the folks in the forum thread have to be commended for providing valuable feedback during the beta testing process.

Related But Not Required Reading: Why Hover Menus Do Users More Harm Than Good

27

27 responses to “Some Not Happy With Flyout Menus”

  1. After testing the new flyout menus, I was so busy playing around with it that I failed to notice you can ONLY have one admin menu expanded at any one time! This seems like a step in the wrong direction. I often have more than one menu expanded.

    Flyout menus are cool, but if they are at the expense of being able to choose which admin menus you can leave expanded, are they worth it? I’m not so sure now.

  2. I think these are very much a step in the right direction. This is the reason I have been using the Fluency plugin for so long.

    It saves screen real estate and doesn’t make you scroll up and down endlessly. Having multiple sub-menus open on the prev. WP meant that the page could become cumbersome.

    If this leads to a revolt I hope they at least make it an optional feature you can enable per user profile (like the visual editor)

  3. Didn’t like the idea at first. But I played around with the development version, and it’s clear that the flyouts make navigating the dashboard much faster. It’s actually been painful to go back to some live sites I have where I have to expand/contract the menus manually.

  4. I’m like yourself Jeff, I think they’re great, no problem here at all. Granted, it’s another change, and pretty much everyone hates change. It’ll always take time for people to get used to the new stuff, they’ll either like it, or they’ll not! — Saying that though, I can see the arguments people are making in that thread, the outcome is going to be interesting that’s for sure!

  5. I can see some of the arguments. A lot of the debate is descending into “I don’t like it, so it’s a bad idea.” That, and it’s beginning to get very charged emotionally, which is always a bad sign for what began as a rational discussion.

    Will the feature stay in 3.3? Yes. The point of a beta is to trouble shoot bugs and get a release candidate ready. Disliking a new feature is not a bug. Will everyone be happy with the feature in 3.3? No. And there’s already at least one plugin floating around that forces the menu system to display in the old-style all-expanded format.

    That’s the beauty of an open source project – if there’s something about it you don’t like, you’re free to make changes.

  6. @Eric Mann

    I can see some of the arguments. A lot of the debate is descending into “I don’t like it, so it’s a bad idea.” That, and it’s beginning to get very charged emotionally, which is always a bad sign for what began as a rational discussion.

    That said, it does appear that this change has been implemented with an accessibility blind spot (pun intended). Kevin John Gallagher makes a great point. Accessibility may be an edge case, but as WordPress becomes more prominent as both a CMS and as a blogging platform, it is an edge case that can’t and shouldn’t be dismissed simply because it is an edge case.

    And that said, Jane Wells knows what she’s doing WRT usability, and I trust that she and the UX group will address this issue.

    As for the “I just don’t like it” crowd: if a Plugin hasn’t already been released, I’m sure one will be released sooner rather than later.

    (I always roll with the admin menu collapsed, anyway, so the loss of dropdown menus is no loss to me whatsoever.)

  7. Wasn’t this a feature in the Fluency Admin plugin? I hated that feature and that is why I never used that plugin. I know there are plenty of people who do use that plugin, but it really is annoying. I like how the collapsible menu is currently. It was a great feature when it was added and still is today. I am just not keen on adding drop downs/ flyouts in the WordPress admin UI. It is a little inconvenient and touchy to use. I mentioned this on twitter a couple weeks ago when I was playing around in the beta.

    This feature is definitely a step back, and not a step forward. Maybe if there is a demand for this… why not add it as an option for users, like the blue and default colors? *shrugs*

  8. @Justin Tadlock – Agreed. It just seems shortsighted that no one on the UI team thought losing this ability was going to cause issues?

    Personally, I hope there’s a plugin that brings back the ability to make whatever menus I want to be expanded, not expand everything.

  9. The only thing that makes the flyout menus at all usable is the fact that something like 90% of the actions you most commonly use have been copied into the admin bar, in a context-sensitive manner.

    In other words, what makes the flyout menus usable is that most of the time you don’t have to use them at all. Sorry, but that’s just bad design, IMO.

  10. I like the flyouts menu, but i think should be more important, that wordpress need a complete reorganization of the menu, maybe the post, paged, multimedia, links and comments go on top of the window and on the left side all the settings.
    The plugins that add menus i dont now maybe the antivirus plugins goes inside the tools menu. things like that is what wordpress needs.

  11. @Chip Bennett –

    And there’s already at least one plugin floating around that forces the menu system to display in the old-style all-expanded format.

    Isn’t that enough said regarding the need for a per user option, as Blake Imeson said. It will certainly make admin operations on complex sites slower, not faster, as Justin Tadlock said.

  12. As far as functionality, I don’t care either way with the menus. I don’t necessarily see the need for change though. However, I am having a boatload of issues on IE7, which I have to use for the majority of my WP work (not by choice).
    Opened a variety of tickets centred around IE7, one involving the uploader that was successfully closed/fixed.
    http://core.trac.wordpress.org/ticket/18924
    Is the one I have for the flyouts that was closed/fixed, however, the fix doesn’t work.
    Basically the menus on IE7 are unusable. The tuck behind everything on the admin page.

  13. @Bob De Young

    Isn’t that enough said regarding the need for a per user option, as Blake Imeson said. It will certainly make admin operations on complex sites slower, not faster, as Justin Tadlock said.

    I think you may have mis-attributed a quote to me, but to answer your question: no; that’s not generally the way WordPress development works.

    I am reminded of the capital_P_dangit() fiasco, in which the Plugin to remove the filter had ten times as many downloads as the Plugin to add the filter (before the filter became part of core). At the time, I remember Matt (IIRC) saying that reversion of capital_P_dangit would be considered if the filter-removal Plugin had 30,000 downloads.

    So, while I don’t agree with that filter, and am – to be completely honest – ambivalent toward the new flyout-menu change, I understand that what drives core development decisions isn’t necessarily incredibly vocal dissent, nor the emergence of Plugins to change (or revert) functionality.

    The WordPress user base is somewhere north of 50 million users, and the core developers generally make decisions based on what they believe will best-serve the vast majority of those users.

    Now, for better or for worse, WordPress.com drives a large part of that decision-making process, because it represents such a large percentage of the overall WordPress user base. I don’t particularly agree with using WPCOM users in this manner. Personally, I think using WPCOM as a testbed for stability, security, and scalability is fantastic; but WPCOM is a blogging platform, and if its users drive the overall development decisions, then blogging (and bloggers) will remain the driving emphasis of WordPress development.

    Honestly, I see that paradigm in play with this decision. The just write, baby! mentality is blog-focused, and myopic.

  14. @Rev. Voodoo

    Basically the menus on IE7 are unusable. The tuck behind everything on the admin page.

    To be fair, there was consideration for removing IE7 support entirely, but I think that got pushed back a release or two.

    Nevertheless, that is coming eventually. IE7 is insecure.

  15. @Otto

    To be fair, there was consideration for removing IE7 support entirely, but I think that got pushed back a release or two.

    Q. Ok, but when IE7 wasn’t dropped, who loaded up the 3.3 nightly to check to see if it worked before saying “hey, I think this is ready for Beta”?

    A. No-one

    Q. Ok, but when IE7 wasn’t dropped, who loaded up test and release plan and made sure that all the boxes were tickets, such as to check to see if it worked before saying “hey, I think this is ready for Beta”?

    A. No-one

    Q. Ok, but when IE7 wasn’t dropped, Who was the Product owner or Project Manager who put the line in the sand and said, hey it’s ready for beta.

    A. No-one

    According to http://www.w3counter.com/globalstats.php and http://gs.statcounter.com/ IE7 still had a higher percentage of users than IE9 and Safari (all versions including iOS), yet no-one thought to even load the AdminUI to see if it worked???

    You know guys like me, the folks who aren’t well liked because we openly criticise 436 days of paid development time for a plug-in to not-quite replace bbPress, truly can accept UI changes we don’t like. We know that there are going to be compromises to be made, especially in Open Source Software; we don’t moan for the sake of it. But seriously, how do people expect us to “have faith” when no-one on the core/dev/automattic team can even be bothered to load their own software release in a browser with close to a 10% market share??

    As I said on the thread that Jeffro references on WP.org, we’re moving more and more people into the “edge case” category. Moving 10% of internet users into it simply because we thought about not supporting their browser but changed our mind, is a very very scary proposition.

  16. @Otto – Oh I totally understand. All of the issues save 1 with IE7 have been remedied. I totally understand that IE7 is old crap. But I’m still stuck using it at work. So when WP drops support for it, if my work hasn’t upgraded, I’ll be SOL. But until that time…. I just keep hopin I can work on my sites at work!

    I’m totally happy with the response I’ve gotten. I found 4 fairly critical issues (for me at least) which completely blocked functionality. 3 of the items are fixed, 1 nearly so. I don’t care if things look pretty or anything, just want basic functionality. Which I got, good stuff WP team!

  17. Where HAVE these flyout menus been all this time!??? Cannot wait to use it on my production sites – at the moment scrolling up and down the page up and down up and down expand collapse up and down to find menus is SO annoying. Welcome, flyout menus!

  18. @Mark

    LOL a little melodramatic are we? Do you mean, “why HAVEN’T I noticed the flyout menus that have ALWAYS been on there when you hover over the menu icons when the menu is collapsed in 3.2.1”?

    Or did you mean, “in 3.2.1 I am addicted to keeping the menus expanded all the time! I’m SOOOO glad that the new menu in 3.3. will force me to keep them closed! I hate having choices!” Just trying to match the drama. I mean, you really can’t be serious, since 3.2 you’ve had the choice to keep the menus collapses and roll over them to get flyouts…

    IMHO the fact that they are removing the ability to keep the menus expanded in 3.3 is annoying and senseless. Just because people like Mark prefer to have their menus collapsed because they don’t really “use” wordpress (inferred by the use of “my production sites” which implies that you are a developer or designer and don’t actually do anything productive INSIDE of wordpress as a user) doesn’t mean that actual users don’t need the menus expanded. Your viewpoint changes when you manage products, orders, a knowledgebase, etc. I do NOT look forward to having to hover over those menus in 3.3 to edit and manage products and orders.

  19. @Kevinjohn Gallagher – It’s a beta release. Typically, a few things are still broken in our initial betas: Internet Explorer, the blue color scheme, and right-to-left support. (PHP4 used to also be on this list.) We handle those as we go, and typically we’re supported by dedicated contributors who, for some reason, thoroughly enjoy one or more of these pain points. But again, that’s why we just call it a beta, and why there’s always a beta 2.

  20. @Andrew Nacin

    Andrew mate, I totally get that.

    I’m sure as heck not expecting a finished product in beta, but really, no-one loaded the website in IE7 to even look.

    Isn’t there some form of tick box for the core team that says “yes, we loaded [the release] in all of these browsers”? What did the test plan (9 from outer space) say? Who was the release manager?

    (These are rhetorical, i don’t think the core team has to answer to me in any way, shape-or-form. I’m a poor developer, but a not bad process-geek, )

    Y’know, Bugs are fine bro, truly we all expect bugs in beta (especially in IE7!), but to not even load it in a browser with a bigger market share than Safari and IE9 is kinda poor form, cos you just know someone loaded it in their iPhone ;)

    Maybe it’s just me, and heck if it is, that’s awesome… but I don’t think something is ready for Beta if it actually doesn’t work at all. And this Beta couldn’t even be navigated in a supported browser. 3 simple CSS fixes later, we’re back in the game. Woot!!! More WordPress awesomeness… but with just a smidgen less faith in the beta releases, test plan, or release management.

    Happy to discuss it over a whisky in April mate :)

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.