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.