Allow Users to Preview Fonts within the Font Dropdown

[jauyong]

Feature description

As a user I want to be able to see a preview of the font selections within the font dropdown in the stories editor.

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

• AC1: implement the ability for users to preview fonts in the dropdown without having to key in characters via keyboard that triggers a query.

Implementation brief

QA testing instructions

Demo

Changelog entry

[spacedmonkey]

For reference, here is the font selection found in Google Docs.

Dialog only appears in when more fonts are selected.

[spacedmonkey]

Related: #3301

[spacedmonkey]

A quick play around with dropdown, shows that it is possible to have all options displayed.

With font previewed enabled, my browser crashed on my fast 16 core computer. With font previewed disabled, the above screen is what you get. The scroll is not usable with 960+ fonts in the dropdown.

[pbakaus]

Some ideas:

1. Model closely after Google doc dropdown. Pretty sure lots of research went into that one.
2. Render the previews in the list as SVGs or images, if not already done yet (but make them h tags or something with invisible text for a11y purposes, or something similar)
3. Might be useful to show the top 100 fonts or so (Google fonts also has a smaller list), and optionally allow either showing all, or adding more to your local list.

[spacedmonkey]

1. Model closely after Google doc dropdown. Pretty sure lots of research went into that one.

Well there is a reason why I put the screenshots here. The dialog even has a section for 'My fonts'. I think users want to be able to filter between, uploaded fonts, system fonts and google fonts. I would say filtering by type of font is pretty useful.

2. Render the previews in the list as SVGs or images, if not already done yet (but make them h tags or something with invisible text for a11y purposes, or something similar)

I tried to generate the SVGs but couldn't work out a scalable way of doing it on build. Also the SVGs do not reflect what the font looks like in the browser. Google docs doesn't use SVGs for that reason.

3. Might be useful to show the top 100 fonts or so (Google fonts also has a smaller list), and optionally allow either showing all, or adding more to your local list.

I have suggested this before, listing of a smaller group of say 25 / 30 font that are popular and look good. This is for people that quickly want to find a font ( or maybe don't really care about fonts ) without hunting around for special font.

[cathibosco]

It seems very useful to list a smaller group of 30 popular google fonts. It also seem useful to offer system fonts.
Question: We are adding the option for custom color palettes in the editor. Is it possible to add something similar so that editors can create a "favorites" font group from (any) Google fonts that they can easily re-use and preview in the same way they will be able to have custom color palettes?

Do we think this is worth consideration as a solution to this ticket or am I going out of scope here? @spacedmonkey
I can mock up a visual...

[swissspidy]

Also the SVGs do not reflect what the font looks like in the browser. Google docs doesn't use SVGs for that reason.

For the preview, Google docs loads the font, but only with the characters needed to display the preview. That improves performance and we should try it too.

[spacedmonkey]

For the preview, Google docs loads the font, but only with the characters needed to display the preview. That improves performance and we should try it too.

So I looked into just loading the characters we needed to preview here. But what ended up happening, was that I loaded say Ubuntu with just the characters I needed. Then when the want was selected, had to do another request to the whole font. Which is another load and data downloaded. There is also a possibility of a jump of content, when the font loads in. This resulted in a very jumpy user interface. Which is why I avoided this.

Again, this is why UX is the most improve test step here. @cathibosco can you do that mockup please?

How is a popular font selected? Is it just the ones we had before in the dropdown?

[spacedmonkey]

I spent a little time prototype what this interface could look like. It returns the font selection to a dropdown. By default it show 'popular' fonts when the dropdown is selected. The search, searches all fonts.

https://www.youtube.com/watch?v=TUm5kZr-axE&feature=youtu.be

Above is a mockup.
It is pretty clean and doesn't require much of change, but it does mean it not clear that user search for fonts that do not appear on this list.

[cathibosco]

Using Google Docs as a guide:
Here are some mock ups to review
1. The default is Arial - there is no "None" & Change copy to Select Font
example:

2. Use the same breakdown as Google Docs for selecting and limiting the scroll for Google fonts and use Recent Fonts to categorize in the drop down for good user experience.
example:

3. Lastly a visualization of the user flow to get to more fonts to choose from
example as seen in Google Docs work flow:

[spacedmonkey]

Okay, so I see you have basically see what you have done here is just got the google font picker / manager into the story editor context. I think this is a good jumping off point, as I am sure that Google docs team put a lot of thought and testing into this dialog. Some thoughts off the bat.

• We don't currently support fonts of different weights. Not sure why this is. But I know that fonts render very different depending on what device you view on them. A lite font can be very very lite in some browsers. So the arrows next to some of the fonts, should be removed.
• What does this recent fonts mean this context?
  • Recent fonts in this story?
  • Recent fonts that this user has used for all stories?
  • Recent fonts by all users of the site?

Recent fonts in this story would be pretty simple, as it just means scanning the current story pages for text elements and making a list. But the other two options would require story a popular fonts list at a global or user level. How is that stored and how is that managed, are questions we would need to answer here.

• What are the accessibility issues around a dialog like that popping up? I know the current media dialog has had it's issues with accessibility.
• Would this dropdown not have scrollbar? I know if google docs show a dropdown that is to long, it doesn't show a scrollbar. But I am not sure why this is, there is accessibility issues with hiding scrollbars but also just not clear that that is scrollable.
• My fonts will map nicely to the ability to upload custom fonts. Do we expect all the font manage to happen in this dialog? Would this screen allow us to upload fonts here? If not, should they be a call to action to the font upload screen?
• I think we need simpler filter options in the dialog. They should be a filter option by font category, like handwriting, display etc. We should have option to filter, google fonts, system fonts and custom uploaded fonts. Popularity is going to be hard one, as we would have to query google font apis, which we can't do in a scalable way. Also system and custom fonts would not have populuity data?
• Developer note, we would have to write a custom component for this, as this existing search dropdown is will not map to this new functionality.
• Design now, the final design will / should look more WordPressy / Gutenbergy.

Worth noting that many of the existing text blocks do not support font selection. See #3224

[barklund]

I made a dummy UI (just in the browser, no code behind it) to illustrate my thoughts about how this could work.

I don't know about the last sub-menu, but it could for instance have further submenus for each letter or similar. It could also easily be dropped.

The other three submenus (Custom, Native and Popular Google) could also just be a list directly in the component as Google Docs does it - similar to the "Used in this story" list right above. I think that will make it clear, that it's a list of popular fonts, as it obviously doesn't show all 1000+ fonts.

The idea is, that if you search, the other items below are replaced by search results, but with an option at the top to clear search easily and see the regular options again.

I don't know if the small category labels are required, but I like them 😄 – also intended for search results. And adding another category to indicate Typekit, etc would be trivial.

[spacedmonkey]

Good work @barklund

I really like the mockup. The little labels are cool and useful. I think we should keep them for future designs as they are super useful.

This mockup does solve the problem of filter different types of font, like native, google and custom. But doesn't solve the other problem of discovery of fonts. This designs still really depends on you knowing the name of the google font you wish to use. What if I don't know what I want or even the style. I am want to feel out the design by checking out what types of fonts are available. Then you are back to scroll through the long list of fonts again. The one thing I am trying to avoid is massive long scrollbars of fonts.

I know we are not currently supporting mobile, just desktop users, but can we try and design something with mobile / touch in mind, so that in the future we can easily add mobile support. I don't want us to design something now with just desktop in mind and then have to redesign it later when do want to support mobile.

[MackenzieHartung]

@cathibosco per our group sync on Monday this needs UX exploration. I am unable to assign to Sam currently in GitHub. Can you work with Sam to take a stab at the UX exploration here, and determine best path forward. Once done, I can add acceptance criteria.

[cathibosco]

The UX team reviewed this closely and we will also review with Vamsee. Our recommendation is using the Google Docs model but the styles from the block editor. I dropped a low-fi screenshot of Google Doc font selection into the mock up above - but it will need to have the styles from Gutenberg UI.

1. The default should be Arial - there is no "None"

2. Change copy to Select Font (from Font Family)

3. So the arrows next to some of the fonts, should be removed for those font variations are not supported. Yes

4. What does this recent fonts mean this context?
   Recent fonts in this story?
   Recent fonts that this user has used for all stories?
   Recent fonts by all users of the site?
   Good question, It seems like Recent fonts that this user has used in stories. would be very useful, but recent fonts in this story would be a great starting point as it just means scanning the current story pages for text elements and making a list. yes.

5. I understand we still need to resolve the More Fonts accessibility issues and scrolling. I'd like to have a sync meeting on this aspect of the challenge to talk through it.

[spacedmonkey]

The default should be Arial - there is no "None"

This is a change in existing behavior. Currently text can have no font set and it will fallback to whatever is setup in the theme. This would not be Arial. Unless we force old content to be Arial,which I am sure existing users will hate. I believe this change would break existing content. We can set a default going forward. We should add a filter to allow developers to change the default if they wish.

[swissspidy]

IIRC the default is not theme-specific, but based on the system font (font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen-Sans, Ubuntu, Cantarell, "Helvetica Neue", sans-serif). So I'd rather use Default instead of None as the default

[cathibosco]

Default is better than none - thank you for explaining the current existing conditions @swissspidy and @spacedmonkey

[cathibosco]

Being able to set the default font is a great options for users, and potentially a higher priority than custom fonts for a majority of users, especially since we have all Google Fonts available.

[spacedmonkey]

Guternberg team are looking into another accessible select menu. See detail here WordPress/gutenberg#17926 .

This PR uses downshift. An example of which you can see here. See need to discussion if we are also going to implement downshift or go our own route with this piece of work.

[cathibosco]

After a design review:
We are pausing work on #3315 and #3316. We should only be focused on #3317. Management of font is not prioritized right now, just the ability to find and see the available font is good enough.

Default to Arial.
Current font picker should only allow users to find font from a selected library of font on the picker.

Here is a low-fidelity mock up - wanted to get this info to everyone as quickly as possible since we are blocking engineering.

[spacedmonkey]

I am a litte confused by the mock ups. Can a user still search for google fonts? Or we just saying these fonts?

[barklund]

Current font picker should only allow users to find font from a selected library of font on the picker.

Isn't this what we started with before adding all the google fonts 2 months ago?

This doesn't really seem like progress, but might just reflect that the move to having all fonts available wasn't properly thought through in the first place.

[cathibosco]

An editor should be able to enter the name of their desired Google font.... to use it.
An editor should be able to preview the same fonts being used in Google Docs...
The rest is being placed on hold as we undergo the larger, holistic UX work for Stories.

From Sam:

1. Current font picker should only allow users to find font from a selected library of font on the picker.
2. Only display a portion of available fonts. Do not display all thousand of them
3. Allow users to type in name if they know it to find the font (look-ahead)

[spacedmonkey]

We have released the version of that allowed users to pick from 1000 fonts. I know we are still in beta but it not a good move to remove functionality that user may be using currently.

An editor should be able to enter the name of their desired Google font.... to use it.

Allow users to type in name if they know it to find the font (look-ahead)

In the mockups it looks like you are converting it from a text search field to a dropdown. How will users enter the name of their desired google font? How do we make it clear that is the field is a combo text field and select dropdown.

An editor should be able to preview the same fonts being used in Google Docs...

This isn't clear to me what exactly this mean. Can you explain in more detail.

Only display a portion of available fonts. Do not display all thousand of them

Where and by who is this list defined?

[cathibosco]

Correct, we do not want to remove that functionality to pick form 1000s...

Is it possible to preview the short list like Google Docs does while allowing for the search?
I understand you are saying we would need a search field and a separate dropdown to accomplish this currently. That makes sense.

[cathibosco]

Do we have "look ahead" or "auto populate" available? Yes we do, for some reason it was not displaying well on my site a while back. It is now.

[samitron7]

@swissspidy @cathibosco @jasti @spacedmonkey Hi folks. See the attached mocks for an interim solution to the font picker. Jonny, let us know if this is all doable.

In short we would like to

• Allow users to see a short recommended list of fonts similar to the one Google provides on their cloud products (Slide, Docs etc). If a font on the recommended list from Slides is not available in our editor we should not offer it. Let us know if we need to be more specific on the list of recommended fonts
• Allow the user to search for a font. Currently if you type in 'ro', it surfaces in alphabetical order fonts that contain the letters 'ro'. What we want is to surface fonts that start with 'ro' first.

[spacedmonkey]

I did some prototyping when this ticket was created. Funnily enough my prototype is very similar to the above. So you can see this prototype in action in this video

https://www.youtube.com/watch?v=wHBzpA25w8k&feature=youtu.be

Some key differences.

• There is still a scrollbar for the list of fonts, as this helps users will limited screen height.
• The icon for the select doesn't change to a cross. I thought of this but decided against it. It was confusing what the cross does. Does that clear the search field or clear the selected font.
• There is a clear 'Clear font' button. This is a little ugly right now, but it is accessible and clear what this button does.
• There is a message under input field to explain that it is a typable field.
• Arial is not default as this not possible as this font is not allows available on systems. I working on Linux at the moment and don't have it. We default to system default (what the OS uses as it's font) and this behaviour should continue.
• Styling is more gutenberg like, with icons and highlights feeling more part of the editor.

I would like some feedback on this prototype.