-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Revert the "Manage fonts" button #65574
Comments
Maybe the design language needs to adapt to the users needs not the other way around. |
Sure, but not in a one-off method that is unique from all other instances. We should not push forward ideas we know are not sustainable long term. Instead, we need to rethink this from a holistic view—not a one-off change here and there. That's how the entire panel ended up in its current state. |
Based on previous discussions in #62129. I believe this could use further contributor community input. The previous Are there alternative solutions beyond reverting? 🤔 |
As I've mentioned a number of times, we really should not push something to core, knowing it is not a viable solution—that it will change again. This one-off UX affordance is not supportive of the WordPress experience. I've proposed an alternative previously, though it could use more ideas. Either way, I still strongly consider the current implementation a regression in UX, not an enhancement. |
@richtabor - Thank you for linking to the proposed alternative solution. My opinion - The proposed alternative does not seem to provide an obvious user experience and would be a regression from the original
It is hard to qualify or quantify what the "WordPress experience" you are speaking of, and perhaps expressing in greater detail what you feel this experience should (or should not) entail for WordPress might help shed light for other contributors to frame their thoughts around.
I'm grateful for you sharing your critical insight and opinions. These are both crucial to this dialogue. ❤ |
As 6.7 is approaching and we haven't reached a consensus, I think I'd vote for reverting the button until we can find a better design and preferably test in Gutenberg first. IIUC, this button was not present in the previous versions so removing it won't be much of a regression. WDYT if we punt it to 6.8 for more discussions? c.c. @getdave in case I'm missing something obvious 🙇. |
I agree. Revert the addition of the button in 6.7 and revisit for further discussion in Gutenberg. |
I'm fine with reverting, and I was mostly concerned this was already in WP stable (6.6), but that seems to not be the case. 👍 |
I disagree with the revert as this change solved an issue that was directly reported by users. I do realize the final decision is up to the release leads though, as well as the responsibility to not address the original issue. Note: for better process, I added the same GitHub labels from the original issue and PR that implemented this change. |
It's not clear there was consensus to add the "Manage" button in the first place, and the closest we have to a concensus for the moment is to revert that change and focus on alternatives. |
Thanks for all the discussion here. We have agreement from the WP 6.7 Editor Leads and the WP 6.7 Design Lead that this should be reverted. Therefore that's the route we will take for 6.7. Please see #66107. A reminder that we can continue to explore a solution as part of wider improvements. |
@richtabor Please read the feedback in the support forum: https://wordpress.org/support/topic/manage-fonts-not-showing/ |
Thanks for reporting the support forum thread @Carolina. I will reopen the original issue as this revert isn't beneficial for users and goes in a direction where ignoring direct feedback from users appears to be a new design trend. |
The revert was necessary as the proposed solution was not valid. Propose something that makes sense and is a valid approach within the existing conventions and there's a chance to move this forward. |
The "Manage fonts" butto (added in this pr) is far too prominent in this iteration, especially accounting for the entire panel's contents. It's adding unnecessary complexity to the UI, introducing another type of control to the already disjointed view.
I'm fine with testing alternatives, but not a solution that fundamentally exists outside of the editor design language. A list of choices, with a button all the way at the bottom is not ideal.
Commented originally here.
The text was updated successfully, but these errors were encountered: