Make the fonts management modal dialog more discoverable #62129
Conversation
afercia
added
[Type] Bug
|
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 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. |
afercia
force-pushed
the
try/make-fonts-management-modal-dialog-better-discoverable
branch
from
4f2963b to
ac8c53b
Compare
|
Size Change: +16 B (0%) Total Size: 1.76 MB
ℹ️ View Unchanged
|
There was a problem hiding this comment.
Personally, I prefer this approach because I think it will make more sense in the future when the font panel is grouped into two parts: user and theme (See this comment).
@WordPress/gutenberg-design I'd like to hear your thoughts.
afercia
force-pushed
the
try/make-fonts-management-modal-dialog-better-discoverable
branch
2 times, most recently
from
8bc7d42 to
1ca155e
Compare
afercia
force-pushed
the
try/make-fonts-management-modal-dialog-better-discoverable
branch
from
1ca155e to
13729a7
Compare
|
I could go either way. Generally these full-width buttons in the Inspector are 40px, but that might be overly prominent in this case, so 32px could work. |
|
Worth reminding that when there's no fonts installed, the current UI already shows an 'Add font' full-width button. Its height is 36 pixels. I'd rather make both buttons 40 pixels for consistency with the new size and other buttons like the ones to set a featured imager or add a background image.
|
afercia
force-pushed
the
try/make-fonts-management-modal-dialog-better-discoverable
branch
from
13729a7 to
d803f99
Compare
|
Screenshot of the buttons using the 'next 40 pixels height', which is more consistent with other similar full-width buttons:
[screenshot updated] |
afercia
deleted the
try/make-fonts-management-modal-dialog-better-discoverable
branch
|
The "Manage fonts" button is far too prominent in this iteration, especially accounting for the entire panel's contents—not just this one component within the panel, as the screenshots are focused on. It's adding unnecessary complexity to the UI, introducing another type of control to the already disjointed view:
I'm not opposed to an empty state, perhaps not unlike the featured image/background image buttons. But I do propose we revert go back to the settings icon, at least until there is a step forward that is congruent with the rest of the panel (and best-case uses an existing UX pattern). |
I kindly disagree. The prevalent feedback from contributors on this issue agrees that the Manage fonts button needs to be more visible. The change is consistent with other buttons used in the UI, see screenshot above with a few examples. Repeated, though anecdotal, feedback from users reported they can't find the manage fonts button as the |
It's consistent with parts of the UI that are not exactly related; the use of those combination of button styles is uncommon, while the placement against the MenuGroup is not used elsewhere. I don't think we should be introducing many new UI conventions; the editor is already complicated.
I'm fine with testing alternatives, but not a solution that fundamentally is not part of the editor design language. A list of choices, with a button all the way at the bottom is not ideal by any means. There's also a concern of placing the button at the bottom of the list of fonts. While this may look fine in the context of a few fonts (isolated in screenshots), any sites with more fonts quickly loose out. |
An "add" icon is probably a much more connective element (in the existing placement), even though it's more than just adding fonts—the primary use case is to add (or manage existing fonts). |
I'm open to try to understand why, if you can bring in some objective arguments beyond personal opinions. A recap of the main points for this change:
I'd argue that if users install dozens of fonts, they're doing it wrongly in the first place. Typography should be managed by people who know what they are doing and good typography should not use more than 3-4 font faces. Lastly, |
These are not related by any other means, apart from the button colors:
We can't simply assume the UI should work within a set of constraints that may, or may not, but "wrong."
You're missing purpose here. The purpose is not to make every bit of UI within the editor compete for prominence. It's to apply prominence selectively, to help people to achieve their goals. UX-wise, we have a list of fonts—each of which open the font library, with that font selected (with the available tabs for each). Then we have a bigger button directly below that list, in a fairly prominent style applied, to something that is not intended to be prominent. Sure, the button is more prominent—but is this helpful? Is it helpful adding yet another button to this view that already has plenty of varying UI shapes across it? Objectively, no, this change is not worth making this view more difficult to parse. Instead of seeing "Fonts", "Elements" and "Presets", you see a big blue "Manage fonts" button in the middle of it all. |
I totally agree. Direct feedback from users reports that they can't achieve their goals. They can't find how to open the Fonts modal dialog with the Library tab showing the main view. This change tries to solve the problem by making the related control more prominent. I don't want to repeat all the arguments already mentioned in previous comments, as I think we're looping over the same points. We're in disagreement, which is totally fine. I'm all for further improvements. However, I'm not sure I understand how saying 'no' without providing an alternative solution to a valid problem is any better for users. I'm totally open to alternative solutions, as long as they address the reported issue in a valid, accessible way. I'd encourage you to create a new issue to explore alternative solutions. |
Fixes #55179
What?
Direct users feedback from the FSE Outreach Program and feedback from other contributors reported the font management modal dialog is little discoverable. #58580 was only a partial improvement and only addressed the scenario when there's no fonts installed by making two changes:
Aaicon with thesettingsicon fot the button that opens the modal dialog to the 'Library' tab.Screenshot of current situation:
I can see a few issues with this.
When there's no fonts installed:
When there are fonts installed:
Why?
How?
Testing Instructions
Testing Instructions for Keyboard
Screenshots or screencast
After: