-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Proposal: Revert theme and custom font family groups #63505
Comments
Thanks for the suggestion. The reason for grouping fonts by source is:
Personally, I prefer the current UI where they are grouped by source, just like the other presets (color, shadow, font size). Any suggestions, @colorful-tones, @jasmussen, @afercia? |
To me, what matters most is consistency. first |
I'd tend to agree with Rich: the delineation over source makes sense in the font library itself (the modal), but the inspector context is the context of the document, and should simply show all the fonts that are active. |
The difference is that you setting a font inactive removes it from what is effectively the active fonts list in the Typography panel. The modal shows you all fonts, installed, provided by the theme, or installable. That nuance is key. |
There's a bit of nuance. For color, font sizes and shadows a user cannot remove the active shadows. If they could, I think we should remove the "theme" vs. "user" connotation there as well; making them simply what styles are active across the site. |
For default and theme presets, this is true: for all colors, shadows, and font sizes, you can only change the values, you cannot delete them. Similarly, the Font Library doesn't allow you to delete theme fonts, but instead lets you "deactivate" them. So in the sidebar, it will appear as if the font has been deleted, even if it hasn't. I think this difference is what makes UI decisions difficult.
I think it's necessary to keep theme fonts and custom fonts separate in the modal dialog. Otherwise, if users want to remove all custom fonts, they will have to click on every font one by one to see if it's a custom font, i.e. if the delete button exists. For visibility, I will also send a ping to @matiasbenedetto |
I'm not sure I agree. The editor is already complicated for users to understand. Consistency is key. As a user, I would not understand why fonts are couped in the modal dialog and are not in the Inspector list.
Then, if that's the intent of the list in the inspector, I would argue the UI is not clear and should clearly communicate to users "hey, this is the list of currently activated fonts". But, even clarifying that, visually the UI wouldn't be consistent with the modal dialog. |
Yes, I agree with this. The modal shows you all fonts, regardless of activation. |
They serve two different purposes with the same data. One shows the fonts available on your site (I don't think "active" is a necessary distinction) while the other shows all fonts, whether installed by you, provided by the theme, or installable. They're not one and the same, so they should not be presented one and the same. The separation of theme and custom fonts in the Typography panel introduces confusion, because we're presenting the two purposes into one. |
I could agree to make these two UIs have a clear different purpose. But then, the UIs in the Typography panel should be labeled accordingly to inform users that's the list of available (or 'active') fonts. And that there may be more installed fonts in the Library that aren't active. The UI doesn't clarify this distinction. It should. As a user, I don't understand what is the difference between this list: and this list: |
I'm confident visible fonts in this list imply that they are "active" font. The same as any other UI we have. Like colors for example, if it's listed, it's available. |
Thanks for the feedback. There are currently three ongoing PRs regarding the font library that would conflict with the code changes needed to resolve this issue, so I would like to address this issue once those three have been merged. |
I kindly disagree. To me, it's not clear what this list is. Also, for accessibility any section of settings should be identified by a meaningful heading. Please let's add a heading, thanks. |
No where else do we denote an "active" list of items, when there are no "inactive" items in a list. If you identify fonts in a list (just like when you identify colors), they are a list of available items. And we don't use "active" in the interface copy anywhere. I don't want to complicate the UI further by adding arbitrary context. Now, if we had a list of inactive fonts, then yes "Active fonts" is a meaningful heading. (we don't need a list of inactive fonts.) |
I guess this is the point where our views differ. Yes the editor UI is complicated. To me, users struggle with the UI because of the lack of context. Often, the UI doesn't explain what a certain item or object is. While for some users the visuals may be sufficient to explain an UI purpose, for many other users the lack of text or headings that identify the 'what' is a barrier.
In what way a heading that clearly explains what this UI is about would ever add 'arbitrary context'? Rather, it would add meaningful, specific context. I'm afraid this kind of design considerations keep into account only the visual aspect, which is not what I'd like to see in a project that aims to be accessible and usable for everyone. Information, content structure, semantics are way more important. For what is worth, reverting this UI to exactly what it was before is a no from me. The current UI is unclear. As a user I don't understand what this list of fonts is about because there isn't any context that explains it. As I said earlier, I'm not opposed to use this list to communicate the list of active fonts that can be used in the editor. But then the UI should clarify:
|
Do you feel the same way about color palettes, shadows, font sizes - any group of available presets to use throughout the site? That if they’re present, it maybe doesn’t mean they’re available (active)? |
@t-hamano: Is this urgent for 6.7? It doesn't look like we'll make the RC cut off tomorrow but I can bless the issue if we think it's important. |
I don't think this is an urgent issue for 6.7. This issue is not a bug report, it's just for discussing whether the current UI is ideal and should be reverted, no consensus has been reached yet. Personally, I prefer the current UI. I think one way to move this discussion forward would be to release the current UI as is into WP6.7 and get feedback from users. |
Ok sounds good. If feedback is strong we can fix during beta period. |
At first glance, grouping theme and custom fonts seems like a good idea (as implemented in this pr), but after exploring a bit further, I don't think it conceptually makes sense to do so.
Why?
Only the fonts that are active on my site render within the Typography panel, regardless of if they are fonts provided by the theme, or fonts that I added myself. The source of the font does not matter—only that it is active.
Adding this grouped distinction of theme and custom fonts, without a clear technical reason to have this distinction (other than colors have theme and custom groupings), does not support making WordPress more intuitive.
An argument could be made that colors should also loose this distinction, moving instead to the UX that fonts held prior to #63211. What difference does it make to an end user if a color on a site is provided by the theme, augmented by the user, or a completely custom color?
I think that distinguishing theme vs. custom fonts makes it seem like I cannot disable theme fonts (like colors work) although it is clearly possible in the Font Library. When disabled, the font is no longer rendered in the "Theme" fonts group.
In an effort to push WordPress to be more intuitive, I propose that #63211 is reverted back to a singular fonts group that renders all active fonts.
Visual
In the visual below, I can disable a font from the theme fonts grouping:
CleanShot.2024-07-12.at.16.50.30.mp4
The text was updated successfully, but these errors were encountered: