A Menus Manifesto?

Now that the new menu system patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. is in and working, I’ve been able to start going through it for UIUI User interface stuff. The are some things I think we should consider changing to fit into the WP UI, though based on timing I’m also okay with letting some of it slide until next release if needed. Here are the things on my mind, which hopefully we can touch on during today’s dev chat.

• Icons. The edit/delete/view icons are inconsistent with the way we handle actions everywhere else in WordPress. We have two options here: we can have icons made that will match WP coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. icons, or we can get rid of the icons and change the UI a bit to match existing interaction models. If we go with icons, I’ll ask Ben to make us some that match better, which might be the better part of valor to get 3.0 out on time, rather than trying to make everything perfect. Release early and keep iterating, right?
• AccessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility). The menus function as it stands now is completely inaccessible. There doesn’t seem to be a no-JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. version, which we have to have. It will be clunky and ugly, like widgets, but we NEED to do this. Icons for actions rather than text is an accessibility no-no, which is another reason to move away from them eventually, but the bigger problem is that we need a no-JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. version. I’m emailing the accessibility list to see if anyone there is willing to pitch in and help.
• Little arrows on the left of each item. These should be removed. We use little arrows everywhere else to indicate an open/close functionality. If we need a symbol to indicate hierarchy we could use dashes like some other plugins do, or better and more attractive, just indent the bar itself? We also need to get rid of those little mini-arrows in the modules on the right when you click on View All.
• Everywhere else in the adminadmin (and super admin), the right-left convention is opposite of how it is on this screen. For example, in Widgets, the available widgets are on the left and the completed sidebars are on the right. On categories and tags, you add on the left and see the updated list on the right. It would probably make sense to swap the menu and the menu controls so the controls are on the left and menus are on the right.
• Buttons. The Save button should use the primary button class (blue). It should also be furthest to the right. Delete should not be a button, but a red link, and to the left.
• Display. Like some other people, I’m wondering why each menu has to have its own screen, when it’s generally a pretty narrow column.
• Default menu. When you first go to the menu screen, it says you don’t have any menus, to create one, but that’s both confusing and incorrect. There is a default menu in place using pages (or categories, in some themes). We should either a) (and preferably) Display the pre-existing menu as Main Menu or some such, or b) change the default text to explain that they currently use the default menu, and this screen is for customizing. It’s also highly unclear how someone should name a menu, or what the relationship is between menus and themes. If someone creates 20 menus but none are supported by the theme, what will happen? It should really pre-fill what menus you have available to you, just like it does with sidebars on the widgets screen.
• The click to add icons perform the same action as the page/categoryCategory The 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging. titles themselves. The icons impair accessibility. If we are to have a second addition mechanism, it should be a text link, not an icon.
• The mechanism for adding URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org and adding page/category is inconsistent. Pages and categories have a list from which you can add, while links are added to menu directly. It would be more consistent to create link rather than add link when it’s first entered, then have link appear in a list below, as the pages and categories do, so that links could be added to/removed from menus without just deleting them. This would also follow the principle we established in widgets that you shouldn’t lose settings when you deactivate something like that.
• The metaboxes down the right all show the on-hover gray arrow in the right headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. corner, but the boxes don’t collapse. Either make the boxes collapsible or get rid of the hover arrows.
• Instead of the edit icon, each menu item should have the hover arrow, which would open it to the edit view. Then we should use save/close/delete as in widgets, thus getting rid of the delete icon as well. This is the interaction model for this type of metacontent and should be followed.
• I don’t really see the need for a View link (icon) from each menu item.
• Whatever we do in terms of these changes, hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. need to be included so that Woo can get their own current look back if they choose, as that was part of the agreement.

This is the kind of thing that we need a styleguide for, which the UI group has recently started working on. 🙂

#accessibility, #interaction-models, #menus, #navigation, #ui, #ux