WPBeginner thinks so. According to them, if the admin bar had a More menu, it would provide a consistent interface for users when looking for links added by plugins. Without it, plugins can determine how they will show up within the admin bar which could potentially lead to chaos if you have enough plugins installed that compete for space within the bar. I think it’s a good idea as it would provide one central location for all plugin authors to place a link which would enable us to easily locate the plugins options page. Your thoughts? ∞
Plugin Review – Expanded Admin Menus
If you’re not happy about WordPress 3.3 taking away the ability to vertically expand and collapse menu items, you now have at least one option to bring back that functionality. Sort of. After quite a bit of discussion amongst community members regarding the new menu flyouts in WordPress 3.3, Aaron D. Campbell contributed with a thought out post which concluded with a link to a plugin he created called Expanded Admin Menus.
After activating the plugin in WordPress 3.3 Beta 1, this is what your left handed navigational menus will look like.
Unfortunately, it’s a far cry from what users enjoyed in WordPress 3.2.1. Instead of being able to choose which main menu item is expanded or collapsed, all of them are expanded. That deafening cry of pain you hear is from mouse scroll wheels all across the globe. After using the plugin for five minutes, it was clear to me that it’s even more of a usability nightmare for myself then dealing with the flyout menus. With all menu items presented at once, my eyes have to scroll through each one to find the specific link I’m looking for. I’m presented with too much information at one time making browsing a pain in the neck. If that were not enough, the collapsed menu looks completely different than the normal collapsed menu, probably due to the CSS it uses.
Collapsed Version Of Expanded Menu Items
While I’m not going to discount the use of this plugin because of that particular bug, the bottom line is that this plugin does not solve the problem that the forum thread was dedicated to. It’s not about having all of the admin menus opened or closed. It was the end user opportunity to pick and choose which menus were vertically expanded or collapsed while being able to have multiple menus opened or closed. Nice effort on the part of Aaron to provide an option to users who loved that particular feature in WordPress 3.2 but in its current form, the plugin comes nowhere close to solving the problem.
Some Not Happy With Flyout Menus
In 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
Where Are The Settings For That Plugin?
At the end of the WordPress Developers meeting for September 2nd, 2010, I had the opportunity to ask a random question about WordPress that has been bothering me for some time.
Out of curiosity will there ever be a way to organize the menus at least by alphabetical order?
The question ignited a bit of discussion and I found out that even Mark Jaquith has a pet peeve with the no rhyme or reason approach to plugin top-level menus. Personally, I enjoy alphabetical order menus because I have a sense of knowing where something is going to be with a minimal amount of time searching. It’s a personal thing but the issue is compounded by the fact that plugin authors have taken it upon themselves to add their settings link where they think it should go. Now, I’ve reviewed a couple of pages in the Codex regarding plugin writing and I have yet to find a specific instance where plugin authors are told where to place their configuration menu link. This is what you end up with.
Some plugins have top menu configuration links while other setting menus are buried within other menus. Overall, it’s just a plain mess that I always have to wade through when configuring something. Currently there are a couple of things that can be done to help with this problem. The first is ticket 14769 which aims to create an API for a Settings action link on plugins.php. The second is for plugin authors to add the Settings link to their plugin which can be accessed on the plugin management page like so.
The third option is to install and use a plugin by Whiteshadow called Admin Menu sorter.
This is a pretty cool plugin in that it provides an interface to mix and match the menu system to your heart’s content, including a few sorting mechanisms built-in such as my personal favorite, ascending order. However, the plugin does not enable you to move items from one menu to another. For example, I created a top-level menu item called WP Settings where WordPress Specific settings would be stored. I was not able to move setting links from the right side of the interface to the left under the main menu. I imagine those changes would be overwritten anyways after each upgrade of WordPress.
These are just a few of the options available to tackle this problem. I would love to see some sort of standard operating procedure when it comes to configuration links and plugins but alas, I think the best that we’ll get is methods built into WordPress that makes it easy for plugin authors to add their configuration links in a standard location. In fact, that method is already in place but many plugin authors fail to take advantage of it, most likely due to poor documentation as I could not find anything about it on the Codex. At least with plugins such as the one I linked to above, I can take it upon myself to restructure the links and menus in the back-end so it’s not such a big mess.
Is this a common pet peeve amongst users of WordPress or do you think things are fine the way they are with regards to settings and their link locations?
WooThemes Has And Will Continue To Get Credit
I have no idea what the reasoning is behind the following post but David Perel seems to think that WooThemes needs to be given more credit for their contribution to WordPress 3.0 in the form of their WooNav system. If we rewind back to when the announcement was made that WordPress would finally have a kick ass menu management system and WooNav was going to be the basis for it, the community as well as sites outside of the community roared with cheers and WooThemes definitely got their credit where credit was do. In fact, many authors writing posts about the new menu system gave thanks to Woo for allowing it to be integrated into WordPress.
John O’ Nolan who is really starting to help out with the UX group with Jane Wells has come out with the following post that makes a few things clear regarding credit. In response to Davids post, Adii comes out with a response that is somewhat neutral.
Here is what I don’t understand. What makes ones contributions to WordPress any different or held any higher than someone elses? WordPress is a software project that is larger than the sum of its parts. Contributions are welcomed and many are thankful for those contributions but really, despite WordPress.org giving props to all of those who contributed to the major release as well as major security vulnerabilities, WordPress would be able to get along just fine without giving credit to anyone. After all, it’s about making the software better for everyone, right? I’m thankful for those that contribute to WordPress but if you want me to put a giant banner on my site because I’m using some new feature in WordPress that you had a hand in making, you can shove it.
I’m still grateful that WooThemes gracefully allowed WooNav to be the framework for the new menu management system despite the extensive reworking of the system to the point where there is almost nothing left of the original. I will always refer to WooNav being the foundation behind the menu system meaning WooThemes will get credit now and will get credit in the future but I’m not going to offer a golden throne because of it.
I think John’s closing line sums it all up pretty well.
In summary… there is no BS here.
Justin Tadlock On Menus In WP 3.0
Justin Tadlock has an excellent post online talking about the new menus feature in WordPress 3.0. The post title says it all. Goodbye, headaches. Hello, Menus!. As I have reviewed numerous commercial WordPress themes along with a few free ones, I’ve noticed that just about each one tackles the menu system differently. The best system I’ve used to date was in iThemes Builder which provided the textual names of my categories and then provided check boxes to either show them, or hide them within the menu. There are too many themes that insist on the user knowing which ID numbers for categories they would like to show or hide. Thankfully, the menu system in WordPress 3.0 will help change all of this and provide a standard for all theme developers to go by.
In Justin’s post, he walks users and developers through the new menus feature and explains how to add it to a theme that does not yet support it.
A Look At The New Menu UI
If you’ve been too busy to spend some time playing around with the new menu system in the latest bleeding edge version of WordPress, WPEngineer has a couple of screenshots of the latest user interface that will be part of the 3.0 release for managing menus. A couple of the comments mentioned that based on the screenshots alone, it was clear that it would be difficult to scale. I’ve played around with the menus for a little bit and I was able to create five of them before the sixth menu forced the menu widget to the bottom of the screen. One of the only complaints I have with the system as it stands now is a cosmetic one. Since the menu addition widgets are on the left hand side and the menus are on the right, it looks totally different than most of the other pages throughout the administration page, especially the widget management page. It’s not a huge issue but I think it detracts away from the consistency of the back-end. Here are two screenshots showcasing what I mean.
5 Menus
Widgets Have A Sidebar Content Sidebar Layout
I suppose if the menu addition item sidebar were moved to the right, leaving the menus in the middle, it just might address the consistency factor. As for actually using the menus, I love the idea of not being limited to category or page links per menu. I can mix and match them as I please.
By the way, I’ve decided to add one more screenshot of what the WooNavigation system was like before it was hacked to death. There are some things that didn’t quite mesh with the surroundings such as the icons but just about everything else seemed native to me. I’ve not had the opportunity to use WooThemes version of the menu system but just from watching the video, it seems easy enough.
It will be interesting to see how the menu system will change either UI or functionality wise before the release of 3.0. I’m also looking forward to reading all the feedback around the menu system once it hits the public’s hands although many who upgrade right away may not even see the menu system until they upgrade their theme with the required functions.
In Depth Page Menus And Page Listings
Jeff Starr who is one of the co-authors for the book Digging Into WordPress has published a great article that goes in depth on various ways on how to display WordPress pages.
The first, most-commonly used tag is wp_list_pages(), and the second, lesser-known tag is wp_page_menu(). First we’ll explore the highly flexible wp_list_pages() template tag, and then we’ll dig into the new wp_page_menu() tag. Along the way, we’ll check out some delicious recipes, tips and tricks for creating the perfect WordPress Page Menu.
On the topic of pages, we’ve had two interesting threads popup in the forum. This one which deals with wp_page_menu and this one which asks the question what the constraints are for WordPress pages.