Font Library: consider making the library more discoverable

[annezazu]

Pulling in feedback from the FSE Outreach Program's Final Touches call for testing:

I clicked the “Aa” icon to open up font management just because I followed your instructions, but I couldn’t have found the font management easily without them. I love icons, but this is only visible with a label.

I've heard this from a few folks at this point and it's clear that this feature isn't easily discoverable. Perhaps we could consider it as part of iteration for design details: #53483 but for now I wanted to open an issue to gather this feedback.

[annezazu]

As a conversation has continued over in both this PR to replace the Aa icon with text and an issue to replace the Aa icon with text, I wanted to bring in a current design proposal to discuss and move forward for WordPress 6.5:

I think there's potential to refine the Aa icon itself to better represent typography, but the cog icon is already widely used. We could potentially replace it with a plus, or an ellipsis. The thing is, once you have fonts, the management stuff is secondary (or even tertiary) in importance.

What we can do is add this button when there are no fonts installed, like so:

The feedback about the above proposed design highlights how Aa icon remains unclear to leave in place after fonts are installed. One can imagine a situation where they click Typography > Add Fonts > they add a font > and then they are unable to understand where to go next to manage those fonts. While it's not necessarily something of primary importance, discoverability and that initial drop off are (still) coming up as points of feedback. @t-hamano suggested adding using the edit pencil button that appears throughout the site editor interface to communicate the ability to edit something a next step.

What iterations can be done as feedback and various solutions are being explored?

cc @afercia @jasmussen @richtabor @t-hamano @carolinan @earnjam

[annezazu]

The following are showing various icons that can be used instead of a new icon, which seems to be part of what's causing confusion. After someone installed fonts, this icon is what would then be used to manage them. This feels like it strikes a good balance of familiarity throughout the interface and matches the level of importance (installing fonts primary vs managing fonts lower). The key is figuring out which works best.

Edit Pencil icon
Here's a look at the above design with a change in icon to be the edit pencil as that matches what we have right now for edit styles in the Site Editor.

edit.icon.mov

This matches what @t-hamano suggested before!

+ button icon

Another option that @richtabor brought up as we were chatting about this is the + button, which matches what's in place for colors:

plus.button.mov

Settings icon

@richtabor also brought up the settings icon which might better reflect the "manage" aspect:

settings.icon.mov

Summary

Finally, wanted to note this issue around discoverability by adding a command to the command palette to open up fonts as well which should also help #54880

[richtabor]

I like the settings icon when there are fonts; + icon when there are not. It's already familiar and expected.

[t-hamano]

My feelings about each icon are as follows, and I prefer the edit icon.

edit: In the Font Library, we can activate, deactivate, install, and delete fonts. So, if fonts already exist, I think this icon is the closest to the context in the context of "edit".

cog: This icon feels a bit exaggerated, as it represents a more global level or app-wide “setting”.

plus: If we don't have any fonts, we should always start by installing them. This icon seems to make sense if we don't want to display a button with text like "Add Fonts".

settings: This icon is used to change query conditions in the query block and toggle custom size input in the block sidebar. This icon seems to have a strong meaning as "settings" rather than "edit" to me. I feel that the role of the font library is closer to "edit" than "settings".

Based on this, I would like to propose the following new experience.

• If the font does not exist, display a button with the text "Add font". No icon is displayed. It also doesn't display the text "No fonts installed".
• Displays the edit icon if the font exists. The button with text is not displayed.

435daef84f63e75b64c1ccf031b96a68.mp4

Alternatively, we might want to display the text "No fonts installed" and a plus icon if no fonts are available.

[afercia]

I like the settings icon when there are fonts; + icon when there are not. It's already familiar and expected.

I'm not sure changing icon conditionally would contribute to UI clarity and help users.

Based on this, I would like to propose the following new experience.

If the font does not exist, display a button with the text "Add font". No icon is displayed. It also doesn't display the text "No fonts installed".
Displays the edit icon if the font exists. The button with text is not displayed.

I would have preferred to not use button icons at all. Ideally, these kind of alternative design choices should just be A-B tested with a group of testers of diverse abilities instead of being left to personal argumentation. In absence of user testing, there's prior research and guidelines to follow. They all highlight that icon-only controls have inherent accessibility problems. From designers in this project I expect accessible and inclusive design.

That said, if there is a strong opposition to using buttons with visible text, I'd then second @t-hamano proposal so that we'll use at least one button with visible text 😄

[afercia]

Relevant feedback about this issue has been reported also on #58082 which brings in accessibility considerations too. Please take into consideration feedback and proposal from that issue.

[colorful-tones]

I agree that the icon as it exists is not ideal and located in an odd place.

After reading through #58082 and this issue (55179). I think @afercia is on to something here:

I think we should strive for consistency and establish a new pattern for all buttons that open a modal dialog. If it was up to me, I'd place a 'Manage all fonts' button at the end of the fonts list. Something like what is illustrated in the following example screenshot:

[richtabor]

The simplest solution, that aligns with existing user expectations/experience in the editor, would be to use the settings icon in place of the Aa icon. I say we try this.

[noisysocks]

I've implemented those two suggestions in #58580.

[annezazu]

Let's leave this open as a place to gather feedback with the above changes in place, especially as we head into beta 1 and inevitably more feedback is likely to come into play with a chance to possibly iterate again or keep as is.

[annezazu]

Moved to "done" for now purely for organizational purposes to focus remaining efforts on items that haven't had attention or that need more urgent iteration.

[afercia]

The simplest solution, that aligns with existing user expectations/experience in the editor, would be to use the settings icon

I'm no sure I understand the statement that using the settings icon 'aligns with existing user expectations', when the actual users feedback that comes from the FSE Outreach Program reports the opposite. Feedback from other contributors and accessibility specialists also reported that this feature is very little discoverable and an icon isn't sufficient.

I'd like to bring in one more consideration. The Font Library is one of the most important new features in WordPress 6.5. It's probably _the most awaited feature in 6.5.

I'm not sure that hiding the fonts management behind a small, pretty obscure, icon is ideal from a product management perspective in the first place. One more reason to make this feature more prominent by using a button with visible text.

[colorful-tones]

Hi folks,
We are only one week away from the Beta 1 cut-off date for WordPress 6.6. This issue hasn’t seen any movement in a while, so we (the editor triage leads of the 6.6 release) have decided to remove it from the WordPress 6.6 Editor Tasks project board.

[noisysocks]

Think we can just mark this as closed by #58580. If the UI needs more work then I'm sure we'll hear about it in a new issue.

[afercia]

I'm not sure this issue should be closed, as there's still improvements to consider.

#58580 only made improvements when there's no font installed. However, when there are fonts installed, teh UI isn't clear. See screenshot:

The 'settings' icon doesn't tell me that's the place to open the Manage fonts modal dialog at all.

More importantly, there's still direct feedback from users coming from the FSE Outreach Program that hasn't been addressed yet.

In #58082 there's a clear proposal to add a 'Manage all fonts' button at the end of the fonts list that hasn't been addressed.

As such, I'm reopening this issue for further consideraiton.

[afercia]

I noticed one more detail that should be reconsidered and I'd call it an UX flow bug. When a theme doesn't provide any font and there's no custom fonts installed, the 'Manage fonts' icon button opens the modal dialog and shows the 'Library' tab, which is empty. There's no great point in bringing users to an empty tab where they can't do anything.
In this scenario, only the 'Add fonts' button makes sense. The 'Manage fonts' doesn't, as there's nothing to manage.
I noticed there's also an e2e test about this scenario that appears to be based on a wrong assumption.

[afercia]

I'm reopening this issue after the revert in #65574

This issue was created after direct feedback from users who were confused by the fonts list and couldn't find an easy way to 'manage all fonts'. An attempt to provide a clearer UI was tried in #62129 and then reverted in #65574 based on personal opinions and with no user testing at all.

Now, a few days after the WordPress 6.7 release, users are reporting again they are confused by the fonts lists UI. See:

#65574 (comment)
https://wordpress.org/support/topic/manage-fonts-not-showing/

For the future, I would greatly appreciate any UI design to take into account users feedback over personal opinions. Keeping ignoring direct feedback from users doesn't seem the best way to provide a clear, easy to use user interface. Thanks.

I'd encourage the design team to provide a new design and solve the underlying source of confusion in this UI.
Cc @WordPress/gutenberg-design

[richtabor]

For the future, I would greatly appreciate any UI design to take into account users feedback over personal opinions. Keeping ignoring direct feedback from users doesn't seem the best way to provide a clear, easy to use user interface. Thanks.

100%. And I'd appreciate if we propose solutions that do not further complicate, nor deviate, from the existing conventions of our application. Otherwise they will not be approved.

[richtabor]

Also, for https://wordpress.org/support/topic/manage-fonts-not-showing/, rendering the manage fonts button will not resolve the user's confusion. It's unrelated. Instead it's confusion about expectations.

This is very confusing. If on the Fonts listing, there is an option to manage the fonts, but in reality the fonts in a typeset can’t be changed, why show the option?

and both of these are the same:
#65574 (comment)
https://wordpress.org/support/topic/manage-fonts-not-showing/

[carolinan]

No, that comment was written after I pointed out to the user where the option was, with a screenshot.
Here is a quote from their first post:

When you go to the Typography section, there is no Manage fonts option.

[richtabor]

No, that comment was written after I pointed out to the user where the option was, with a screenshot.

It does not change what their intentions were, and what they were confused about. Adding a button there would result in the same core question.

[carolinan]

There is more than one problem. This issue is about making the library more discoverable.

[afercia]

solutions that do not further complicate, nor deviate, from the existing conventions

Have you considered that the 'existing conventions' may be just wrong? 🙂 That's not a good argument.

To me, a few conventions need to be established here:

• Unclear UI sections must have a heading that clarifies what they are about.
• This is a list of active fonts. Users may have 30 fonts installed and the list only shows the active ones, e.g. 10. There's no indication at all that there may be more fonts available other than the active ones.
• Controls that open big modal dialogs must visually and ideally semantically communicate they are going to open a modal dialog. Opening a so big modal dialog may be an unexpected experience for users. I'd love to see a specific kind of styling and verbiage established for buttons that open big modal dialogs.
• The current 'settings' icon for the 'Manage fonrs' button that opens the modal dialog is an inappropriate usage of the settings icon. In fact, that icon is used for entirely different purposes in the UI such as switching controls to an alternate UI etc. As such, this icon in this context suggests an action that is different from what it actually does. I'd like to see the settings icon being an established, consistent, convention to be used only for one purpose.

All this points have already been discussed, this is just a recap. Regardless of personal opinions presented as unshakeable truths, the point is that there's again direct feedback from users that this UI is unclear and confusing.

#62129 was an attempt to make the UI clearer. I'm not pretending it was perfect, but it was better. The argument that it was not inline with existing conventions is close to a personal opinion. To me, that means the existing conventions should be likely audited and rediscussed.

Users don't understand this UI. Ignoring users feedback isn't in line with the WordPress tradition and openness to users' feedback and the commitment to provide an easy-to-use UI. As such, I think the revert was an unfortunate decision made without any effort to gather consensus.