Move Navigation menu title and state info out from Actions button label. #59440
Conversation
afercia
added
[Type] Bug
|
Size Change: +52 B (0%) Total Size: 1.75 MB
ℹ️ View Unchanged
|
afercia
force-pushed
the
fix/menu-actions-button-labeling
branch
from
ce69ee3 to
d7d1b4d
Compare
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the Unlinked AccountsThe following contributors have not linked their GitHub and WordPress.org accounts: @helloakshat. Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases. If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
There was a problem hiding this comment.
@afercia Now there is no way to actually tell which menu is selected without having to move around this panel in browse mode. I agree we shouldn't be updating the label but taking away users ability to see what is selected in that dropdown is not great either. You have to open the dropdown to now see what is selected. Thoughts?
afercia
force-pushed
the
fix/menu-actions-button-labeling
branch
from
d7d1b4d to
0af5511
Compare
|
@alexstine thanks for your feedback.
In a way, that is true for all toggle buttons that open a dropdown menu, for example in the block toolbar: Heading level, Alignment and many other places in the editor. A toggle button that opens a dropdown menu is not supposed to report the currently selected value. Rather, I wonderwhether a dropdown menu is the best UI for a selection in the first place. Also, the dropdown menu contains a mix of things that are logically different, which isn't great to me:
Given the mixed content within the menu, I don't think the toggle button should ever contain information about the currently selected menu. In my opinion there are more things that would beed improvements and I'm totally in favor of making the selected menu information available in focus mode as well, in some way. I'm open to suggestions. With this PR, the information structure is the following one:
All this labeling could be certainly improved. Thoughts? |
|
While fixing the |
|
@afercia I agree, labeling needs to be cleaned up for the list view. Adding the application role was necessary though due to the fact NVDA will always switch to browse mode if you pressed right arrow and landed on the block options button. The bug has been reported to NVDA developers and will not be fixed without additional funding. What is frustrating about the submenus is these are used all over, as you said, to select/change UI views. There is no good way to communicate the currently selected value and I bet you 100% we're not going to start replacing them with something that makes sense such as a simple HTML select. I have no ideas on how to improve something that is by default, an inaccessible misused pattern. |
Oh yes I would have liked to see a selection feature actually use a control that is made to... well... select. @alexstine what if we change the heading? Currently, it's 'Menu', which doesn't help much. |
|
I looked at this and it looks like below: navigation-label.mp4Although it does solve a legit problem the resulting UI is quite out of place. If we intend to address the problem via UI we need to integrate things a bit better into the overall design. The thing that is hardest is that, despite its existence, the name of the currently selected "menu" is not important in most cases. And in the cases where it's important it's because there is a slew of other menus, and seeing the active one in a list of all is more useful for sighted users. OTOH, for sight assisted interaction the fact that the selector announces the name of the selected menu is quite useless, and the currently selected menu becomes a matter of hunting for it. Can we solve this without bubbling it up as a visible update to the UI? If we have to update the UI we need some sort of polish to the solution IMO. |
afercia
force-pushed
the
fix/menu-actions-button-labeling
branch
from
ecdc501 to
129de9c
Compare
|
Rebased on top of latest trunk after #59667 |
|
@draganescu Could you please explain your comment?
It sounds like once again, we're going to do everything in our power to ensure sighted users have a great experience and people without sight, well, get left out. I'm of the opinion that a visible menu name would be an improvement that saves clicks for everyone but I guess not. |
|
Oh the coldness of the comment box strikes again 🥲 By all means @alexstine I was trying to convey precisely that the fact that:
is a serious bug for sight assisted interaction because there is no way to know that from a control named "Header Navigation" one can switch to another menu 🤦🏻 . What I want to add to this is that in solving this bug we need to think if there is a way in which to not prominently show the navigation name in the UI since in 80% of the cases it's irrelevant, users generally building one menu, maybe two. Also, if we can't do it any other way, and must show the label then and there, we need to do some massaging to that label's integration b/c for now it looks quite patched on top of the UI. For instance, if I have a menu labeled Navigation it the visual hierarchy is very confusing since I am already in a panel with a big bold title Navigation. |
|
@draganescu Why not something like "Currently editing: menu_name"? I think a lot of Gutenberg's UI challenges could be made better for everyone if it were obvious to all. I think the bus starts falling off the road when we make assumptions about the UI and what is useful or not useful. That's what I like about classic WordPress, the UI was so clear, not always the best organized, but clear. I find the whole experience with guessing UX to be quite inaccessible and I know I've seen other feedback where even sighted people get confused. Not sure if I disagree with the 80% here and even if I did, making it clear has really no drawbacks. One extra sentence in the UI hurts no one. This could also be solved with a simple HTML select with a create new menu button right next to it. Sometimes I feel like we as developers/designers try to make a UI so simple that it actually becomes more complex. Anyway, just my take. |
|
I'd agree with @alexstine that overall, the biggest challenge I see in the editor environment is how difficult it is to get clear information in the pursuit of having a "clean" interface. I don't think there's any scenario where it's harmful to have a visible name that gives you context about what you're editing, and many scenarios where it's critical. So on balance, I think it's very important to have visible. @draganescu As a note on your video: your comments definitely sound like you're critical of how this PR makes things look, but you didn't include any specifics. I don't see anything in the video that I'd have a problem with visually; can you provide some written description of what you find out of place in that UX? I just don't see what the issue is. |
|
@alexstine I think this bit:
... is really poorly phrased on my side. I wanted to say that having a checkmark in a list does a better job for sighted users but not great for everyone else and we want to improve this, since the checkbox is useful if you can see the list, otherwise the checkbox is not useful. My intent is to say it's not good enough for everyone :) but I can totally understand how it does not convey that. @joedolson the problem is that the label is disconnected from the control below it and looks out of place in general - for example the spacing is wrong because the label is placed in the horizontal layout of the panel title. Also it is raising the importance of the menu's name to the highest UI hierarchy level, whereas this is a power user detail. It is not important in general, not even if there are two or three menus. So while we can show this name it's not helpful but makes things more confusing. @alexstine I think if we just solve the problem with the label of the toggle of the drop down the fact that the name fo the menu is available in focus mode for assitive tech users or via diving in the UI for not assisted use, sort of having this information in a secondary level, for everyone is good enough for a feature which we want to be discovered not assumed. |
I definitely agree that the name of this action button should be changed to a consistent label. It seems like the direction of the navigation menus is to deemphasize named menus. However, as @draganescu is saying, access to this information is easier for sighter users, and it should be easy for everyone who wants that information. I understand @draganescu's point that putting it into the main UI makes the UX worse because the name of the menu should not be important. We want the selected menu name to be deprioritized for everyone. Would attaching the currently selected menu name via
FWIW, this is my personal preference too. If it were 100% up to me, I would make the title something like, "Menu: [name of selected menu]" |
|
@draganescu thanks for your feedback. I'm not sure I can agree with most of your points though.
Honestly, this is is a very subjective perspective.
I'm not sure I understand how the menu name is not important. In the admin, it is important because it gives users immediate feedback on what the selected menu is without having to scan the entirety of the menu to understand it, and the menu could potentially be made of dozens of items. More importantly, on the front end the menu name is what is used to label the
I will split this to a separate issue as the naming of the menu should be a first, prominent, step in the menu creation and its importance should be explained to users.
Could you please clarify who 'we' is in this context? Are you referring to some specific group of people as opposed to other groups? I'd like to remind everyone that this is a collaborative open source project and there is no 'we' as opposed to 'they'. We are all contributors, peers between peers, each one with their own expertise and skills. I'm not sure usign the term 'we' is appropriate in any contribution to this project. It is also unfair because this same conversation proves 'we' (as we all contributors participating to this conversation) disagree on deprioritizing the menu name. |
|
I would also like to add that the automatic naming mechanism is very wrong as it adds the termn 'navigation' to the menu name e.g.:
I'm pretty sure prior accessibility feedback on various issues and PRs already explained several times that a navigation |
|
👋🏻 @afercia - the "we" refers to my understanding of the overarching sequence of design iterations on this block and on the overall navigation building experience in the site editor. I do agree to your points on the relative importance of the name of the navigation. But what is the gain from crafting some weird name ("Menu Christmas Promotion") - and then use that on the front end to announce it, compared to auto generating the name from the surroundings of the block? I say it is no gain at all, creating yet another way to make simple mistakes. Also I think, again, you're right, ideally if there is a name it should be asked upfront, yet concretely this is not a menu making application, it's a tiny function of a way more general application. How much UI do we need to communicate the relationship between the name a user writes, in a dialog interrupting their goal whom they can't wait to dismiss, and the label of the underlying I think a lot of design tension comes from the fact that it is not expected that who ends up building a website will go through training as to what exact steps to follow. In it's consumer product shape (one of the shapes of WP) we all (everyone) should strive to make the experience as fluid and seamless as possible. The more that can be absorbed and handled by implemented heuristics the more fluid and seamless the experience is. So to conclude, what we - the folks in this issue and everyone else - have a hard time to figure out is how to achieve the goals without cluttering the UI, burdening users with our problems and the web's technical intricacies, and also at the same time keeping the experience universally accessible and technically correct. It's hard. I find myself agreeing with almost everything you say but filtering for the goal makes me try to seek alternatives which are less straightforward and debatable.
I don't agree with this one though, it's not subjective. The spacing around it has no rhythm, (it's too far from the tree control) there is no informational hierarchy it belongs to. The panel already has a title and all the tool panels have the title in the panel title. If we have no other way, It'd rather put it in the panel title itself, OR use it instead of "Navigation" for the name of the block, which is also how we do for template parts. |
I think we fundamentally have two very different views on what building a website is. While a tool like WordPress aims to empower everyone to publish their content, users with no education and training will end up building a website that resembles Geocities. In the past this was mitigated by the fact themes were under control of theme authors, so that the design, layout, typography, readability, accessibility, etc. were responsibility of web professionals who strived to make their themes the most usable and accessible experience for everyone. Now that the editor aims to put all this power in the hands of the final user, there's a serious risk to make the web worse. As such, there is the actual need to train and educate users on what they have to do.
Yes and no. Sometimes, a smart UI may actually help users with their website building creation experience by automating things. Sometimes no, especially when it comes to the quality of the content. The menu names is content because it is used on the front end. The menu names must be carefully crafted and the UI must explain users why. A similar example would be the alt text for images. I've heard countless times folks suggesting to automate the alt text creation by using AI or other smart flows for the exact same reasons you are mentioning in your previous comment. Unfortunately, all these smart ideas miss a very important point: the alt text, like the menu names, is content. It must be meaningful and high quality content and it depends on the context. As such, it must be created by humans who are trained and educated to understand why this is important content.
I'd be more concerned if the menu creation was a daily task but it isn't. How many times users create menus on their websites? Typically they will create 3-4 menus at the very beginning when they are building their website and then never create new menus again. As such, I think making the menu name a required step during the menu creation doesn't really block the user experience in a significant way. Instead, it would be a good educational opportunity and it will contribute to make the web a better place.
I heard this kind of terminology from designers a lot. "balance", "rhythm", etc. to me are subjective perception unless they can be objectively measured based on specific criteria e.g. design guidelines or a grid system or established patterns for vertical spacing.
I'd argue the root problem here is that, as a user, I don't understand why the concept of 'navigation' is separated from the concept of 'menu'. As a developer, I understand why. As a user, I don't. The title 'Menu' doesn't really help understand how the Navigation block works. It should be 'Current menu' or 'Selected menu' or 'Active menu' or something along those lines.
Section titles should not be used to communicate states or selected values. |
|
Have we considered not putting the available navigation menus in that actions button at all, leaving it purely for actual actions? If the user has only one default navigation menu, there's little point in showing it as an option, or what its name is; there's no choice to be made. And if there are multiple navigation menus, then putting that information up front doesn't seem wholly inappropriate.
|
|
I very much like the idea of being able to see the name of my current menu at all times. The proposed design could be difficult in languages if the translation of 'Menu' is long; but I don't know an example of that. |
|
@andrewhayward thanks, yes I'd agree a Quoting myself:
The relationship between 'Navigation' (the block) and 'Menu' is not clear and the UI doesn't help clarify what it is. To me, this is not much different from the Classic menu 'locations' page where a menu can be 'assigned' to a location. In a very similar way, in the editor a menu is 'assigned' to a navigation block. As such, I'd change the title 'Menu' to 'Assigned Menu' which is a terminology users are already familiar with. Screenshot of the menu locations in the classic menus:
Re: the ellipsis Action button, I think that using an ellispis button with a dropdown menu in this case is fundamentally wrong and inconsistent with other usages in the editor. In the editor, there are severeal 'Action' buttons with a dropdown and, visually, they are directly associated with the object the actions apply to. For example, in the List VIew each item is a block and the ellipsis button shows actions for that block. Same in the datqa views, etc. Instead, in this case the ellipsis button shows actions that are not associated with the object indicated by the title 'Menu':
To me, the title 'Menu' relates to the selected menu below it. Instead, the ellipsis button relates to actions that belong to the Navigation block. Screenshot:
|
afercia
force-pushed
the
fix/menu-actions-button-labeling
branch
from
129de9c to
b5e3604
Compare
Fixes #59431
What?
The label of the Navigation menu 'actions' button in the settings panel provides information about the currently selected menu title or state rather than the what the button does.
Why?
Any control must be labeled based on what it does or on what actions it gives access to. It's not a place to report selected values or states.
Also, consistency is key.
How?
Note:
the latest commit improves a little the 'Loading...' indicator. Previously, this 'Loading...' text stayed there forever after switching to another menu. It is now a little better but I don't think the underlying bug is fully solved. Specifically, I'm not sure the state props
isCreatingMenu,isResolvingNavigationMenus, andhasResolvedNavigationMenuswork as intended. Basically, when switching to another menu,isCreatingMenuis always true, which doesn't seem correct to me and causes at least another bug. I will split this to a separate issue with more details.Testing Instructions
Loading....Loading...text changes to the new menu name e.g. 'Header navigation 2'.Testing Instructions for Keyboard
Screenshots or screencast