From #1542184: Small UX suggestions:

I got confused about how to enable to fonts and manually add them to my CSS file. I assumed by simply enabling the font, I could then use the font in my CSS. This doesn't appear to work as you have to adjust the "CSS selector" drop down from "-- none --" to "-- add selector in CSS --" in order to use the font in CSS.

I would think that enabling the font would then immediately make the font ready to use, without additional configuration, possible.

In other words I think it's confusing that there is a "-- none --" status.

Comments

sreynen’s picture

This has come up in a few different issues. People expect "enable" to, well, enable the font, and it doesn't really. What it does instead is confirm that the font is ready to be used, which means different things for different providers. For some, it means checking the API credentials allow using the font. For others, it means downloading the right files. For others, nothing happens here beyond making the font show up on the "apply" screen.

I'm not sure the best way to remove this confusion, but I think #1397410: Add ability to set selectors from browse interface is probably part of the solution.

sreynen’s picture

Another consideration here: currently Typekit fonts all get enabled on import. Not sure if that still makes sense if "enabled" changes to mean the font loads regardless of the CSS application.

btmash’s picture

Hmm, what if it steps into a form as a part of the enable process (ie. under what rules do you want the font to apply - make it required to add the font). You would be passing through the font, it goes through the 'enable' process of setting up the font if necessary and then the files are setup at that point as well.

And since @font-your-face ui requires ctools (due to views), you could actually tie the form page to a modal - if the user has js enabled, show the modal, they fill it in...I imagine it could be even more awesome than it is right now. :)

sreynen’s picture

That sounds like the right direction, but that leaves us with 3 places to choose CSS selectors, so I think we need to also get rid of at least one of the other two: the apply screen and the edit screen. I think adding new, better interfaces without getting rid of the old interfaces that do the same thing is a large part of the current confusion. I made a new meta issue to try to figure this out on a higher level before getting into the details: http://drupal.org/node/1544156

neslee canil pinto’s picture

Issue summary: View changes
Status: Active » Closed (outdated)