[OTVar] hidden axis flag

Peter Constable

One thing that was obvious at the Typo Labs conference was that there isn't any consensus yet as to what the right UI should be for selecting instances of variable fonts, though there a couple of related thoughts I heard that I think may gain some traction: a lot of options becomes a problem for users, so if an axis can be set by automated means and hidden from users, then that simplification of user experience is good.

So, one thing that was clear to me coming out of the conference was that, in the future, there will be a need to have variation axes that should normally be hidden from user interfaces. To reduce the potential that there will be apps that expose such axes anyway, because they don't recognize whatever field in the font indicates the axis should be hidden, I want to get that into our new DirectWrite APIs right from the outset. Hence, I engaged with our partners and we have a consensus for defining a flag within the fvar table (specifically, within the VariationAxisRecord flag field):

mask: 0x0001
name: suppressFromUserInterfaces
description: The axis should not normally be exposed directly in user interfaces.
other comments:

"The suppressFromUserInterfaces flag is provided to indicate a recommendation by the font developer that the axis not be exposed directly to end users in application user interfaces. Reasons for setting this flag might include that the axis is intended for programmatic interaction, or is intended for font-internal use by the font developer. If this flag is set, applications may expose the axis for “advanced” user scenarios, but should not expose the axis in common user scenarios." 

This will be reflected in the next version of the OpenType spec, but it can be considered stable now.

PabloImpallari

Peter Constable said:

... so if an axis can be set by automated means and hidden from users, then that simplification of user experience is good...

This is dangerous... automated solutions are not always right and may fail miserably sooner or later. While it may be good for the average user, advanced users needs to be able to control it manually.

As an example: In photography cameras you have the "Auto" settings where everything is taken care for you. This is great for the average users. But you also have the "Advanced Settings" for the professional photographer, when you can configure every setting to your heart's content.

If OS and Apps are going to get smart and try to guess stuff, please also include an "advanced settings" option for people who want to roll their own settings.

John Hudson

Pablo, those kinds of advanced settings options are the domain of user interfaces, not of fonts. Ultimately, the font maker has no control over what features of a font are exposed in the UI, or ever which are supported at all in a given piece of software. The purpose of the new flag is to enable font makers to offer a suggestion to the UI that a particular feature is intended for for use by programmatic interaction, and hence should not normally be exposed to users. The UI can respect or ignore this suggestion. The UI can offer access to the axes for user override of programmatic interaction (which is very typical of CSS, for example).

And if you, as a font maker, want to ensure that all variable font axes are accessible to users, by all means don't set this flag for any axes.

It may help to consider that the kinds of programmatic axes Peter is talking about might also have corresponding user axes that address the same areas of the variable font design space in different ways. So, for example, a font might have an exposed 'Weight' axis, and a hidden 'Parametric Weight' axis.

Deleted Account

I agree with the axis flag issue of importance. And I agree with a need to recommend hiding some of them from application UI. I have three kinds of axes now, all un-flagged and totally pre-out of compliance on this.

I don't think I agree with leaving apparent ambiguity, with "Normally" or "suppress", hearing Pablo, perhaps others feel the same.

To dispel that, I think you could document that there may be variation axes, and parts of axes too, hidden in the space, that are not accessible to Programs or UI. These axes may be there because either the size of the vf file blow up if not present, or the appearance of the rest of the axes of the font will be modified by use as a normal axis.

To further dispel ambiguity I think you could document that all unflagged axis, (registered or not), should be shown "Normally". If applications are going to decide what normal is, then fonts would have to be able to "say" whether they'll work in the first place in apps that only use registered axis, or worse, e.g. Decover with one registered axis and a horde of strangers.

If that's done, and if we can hide axes we want no one to change, and not flag what we want to show, the Only flag, we need is for "Expert" UI use, and by Programs, and that seems the intent here. But I think that one flag is still 1/2 ambiguous off-thread, in the real-world.

So, flagging every axis from "the beginning" as either, hidden, normal or expert where:

HiddenFromInterfaces has no data for UIs or programs and a flag to a definition of why.

ShowToNormalUserInterfaces has data for UIs and a flag to a definition of Normal.

HideToNormalUserInterfaces has data for UIs and a flag to a definition of Expert.

I think that is probably the least ambiguous thing you can do to cover the most real world issues in a way anyone outside can understand, given examples that exist.




 

Peter Constable

D. Epar ted said:

...

It sounds like you want a three-way distinction:

• Axis can always be exposed in UI.
• Axis should only be exposed in "advanced" UI.
• Axis should never be exposed in UI.

I don't think we'd need three flag bits defined; the first of these can be represented by the absence of the other two flags. In fact, that's better since, otherwise, the absence of any of the three flags would leave ambiguity.

As for a "never expose" flag, why would there ever be a need for that, distinguished from an "advanced only" flag?

PabloImpallari

David, I'm not sure I understand. What would be and example of and axis that would never be exposed?

Deleted Account

Peter: "...the first of these can be represented by the absence of the other two flags."

Nothing meaning something, is usually how flags are defined as an afterthought in specifications. This means today, and forever, every undefined axis will show in UIs, and will likely lead to applications making their own decisions until the flags, tools and registration process has caught up. By then confusion over nothing meaning more than it should, will be rooted. 

Peter and Pablo, a "never expose", or perhaps "please never expose" is requested and I'll give specific examples under which a general theory operates.

First, as I mention in my TypoLabTalk, there is almost nothing one can say about type that's true to everyone in the world now, except perhaps what I just wrote.

Productized versions of Amstelvar and Decovar with proposed flags, as opposed to the experimental open-source fonts you can see, would probably be like this:

Amstelvar- 

Axes can always be exposed in UI, weight, width and opsz

Axis should only be exposed in "advanced" UI. GRAD or a future grad

Axes should never be exposed in UI. The rest, future registered or not.

Decovar- part of what I'd do to productize,

Axis can always be exposed in UI, Blend A, wght

   (Blend A combines Skeleton A and Terminal K, Skeleton A and Terminal K are particularly destructive used alone, Blend A works much better than using Skeleton A and Terminal K along with other terminal axes.)

Axis should only be exposed in "advanced" UI. None yet...

Axes should never be exposed in UI, Skeleton A and Terminal K, so far.

The general theory I'm operating on is within the Script/language, family, style, treatment (including size and grade), mantra, and has two influences, 

   what's the registration status of an axis? if not registered, not interoperable and not

programmable, I'm not exposing parametric axis that have an effect on style or treatments like size or grade, to UI. i am exposing unregistered axes that effect family, like Decovar's various terminal serif types, registered axes effecting style, and other axis that operate well alone, to offer treatments like drop shadows, and layers for color and grades.

   what are the effects of an axis relative to current user experience? Take opsz, and hide in UIs in favor of just responding to the user's request for sizes. I.E. Something somewhere has to give on the UI to opsz, or our user is specifying the opsz and then the size to match. Slightly less frightening, is where apps have not been offering control related to an axis, like Overshoot, which, in a lot of font families with width, weight and optical size axes, is a very complex variable. I will be making an YTOM axis, (y transparent overshoot the messenger), to solve a number complex issues of Latin and inter-script optical alignment. Ultimately YTOM is destined for blending into the (as of now unregistered), y parametric axes, before I blend those parametric axes into the three current registered axis, wght, wdth and opsz. I do not want to expose YTOM, or even a future ytom to UI, because its not in the user's experience to deal with overshoot themselves.

This is not to say there can't be programatic access to these hidden axes. If a numerically -controlled cutting device comes along where the overshoots at 256 point are just wrong for the wrought iron bridge rail pattern, (you don't want to know this has already happened, once), then a programmatic change could be wrought to carefully diminish the overshoots of that size by a per mille determined value. 

John Hudson

So you want are flags for 'Always show this', 'Sometimes show this', and 'Never show this'?

The sometimes criteria are unclear. What does 'advaced' UI actually mean, and who gets to decide? If a developer has a single UI paradigm, should this flag be interpreted as include or exclude the axis?

Nothing meaning something, is usually how flags are defined as an afterthought in specifications. This means today, and forever, every undefined axis will show in UIs, and will likely lead to applications making their own decisions until the flags, tools and registration process has caught up. By then confusion over nothing meaning more than it should, will be rooted. 

Nothing meaning something is inevitable, because default behaviour for software has to be defined. So what should the default behaviour be if an axis does not have a flag defined? Should the font be rejected by the system? I presume not. Should all such unflagged axes never be exposed in UIs? That seems to me more problematic than the current interpretation that unflagged axes should always be exposed. Should individual software developers decide how to interpret the absence of a flag? That's jus a recipe for incompatibility.

I'm totally fine with having unflagged = normally exposed. Defining that as such in the spec is as meaningful as defining a new flag that means the same thing, and means we don't also have to redunantly define a standard interpretation for unflagged axes.

Dave Crossland

This means today, and forever, every undefined axis will show in UIs, and will likely lead to applications making their own decisions

I began with the assumption that this is a reasonable default, but after talking to graphic designers, I think David may be right; they are scared by complexity of too many sliders and being unable to finesse the relationships they need out of too many. 

I also do not think that a default should be for all registered axes to be displayed to users; since the purpose of registration is interoperability, nothing more.

It makes sense to me to have opsz in the always-show bucket, because often typographers like to use the graphic effects of 'tiny type' at display sizes; and display families may also be used at smaller than intended sizes in some graphic design situations. 

---

I also wonder about more detailed metadata to tag axes with indications about which UI may be most suitable for it.

- slider

- dial

- 2d box (2 axes, one along x and one along y)

- 3d box (3 axes, along x y and z dimensions, in a cube, eg using GL)

- time play/pause button, with default state

- time duration input, with default value

- time loop button, with default state

Peter Constable

Re more detailed metadata, I think it's way to early to be guessing at what the best future UI affordances for axes may be.

As John indicates, there is always some assumption to be made when no flags are set. If we don't explicitly say what should be assumed, then different apps will do different things. Also, note that fonts are starting to get created that don't have any flags set, and so the no-flags interpretation should keep those fonts in mind. Do we treat that as the "never show" case, or the "only advanced" (by some determination) case? I think the safest thing is to treat that as "always ok to show" on the grounds that users are less likely to be confused by a variable font that has multiple knobs/sliders than by buying a variable font advertised as supporting axes but then they can never see them in apps.

John Hudson

Dave:

I also do not think that a default should be for all registered axes to be displayed to users; since the purpose of registration is interoperability, nothing more.

I may have missed something, but my understanding is that the proposed flag (or flags) would be valid for both registered and custom axes. The proposal isn't that all registered axes would be exposed in UIs, but that unflagged axes would be. I think that's a reasonable default, especially since it is already the default assumption to which the proposed flag is intended to signal exception.

Dave Crossland

Peter Constable said:

Re more detailed metadata, I think it's way to early to be guessing at what the best future UI affordances for axes may be.

Sure I think it's maybe fine for folks like say Lawrence Penney to keep a database of this metadata, in a central place such that it can be updated and maintained, as things evolve. 

As John indicates, there is always some assumption to be made when no flags are set. If we don't explicitly say what should be assumed, then different apps will do different things. Also, note that fonts are starting to get created that don't have any flags set, and so the no-flags interpretation should keep those fonts in mind.

I think it's way too early to care about that. Everyone selling VF fonts has huge disclaimers saying it's early days and to expect font updates. 

Do we treat that as the "never show" case, or the "only advanced" (by some determination) case? I think the safest thing is to treat that as "always ok to show" on the grounds that users are less likely to be confused by a variable font that has multiple knobs/sliders than by buying a variable font advertised as supporting axes but then they can never see them in apps.

I think it's far more important to set this up to Do The Right Thing By Default, and consider the long term, which will effect billions of people, instead of accommodating a handful of early adopters​ doing things in the last 9 months or less.

Dave Crossland

John Hudson said:

Dave:

I also do not think that a default should be for all registered axes to be displayed to users; since the purpose of registration is interoperability, nothing more.

I may have missed something, but my understanding is that the proposed flag (or flags) would be valid for both registered and custom axes. The proposal isn't that all registered axes would be exposed in UIs, but that unflagged axes would be. I think that's a reasonable default, especially since it is already the default assumption to which the proposed flag is intended to signal exception.

No no, not missing anything; I just want to make explicit that the flag or flags can work for registrated axes too. I am questioning the reasonable assumption of this default. Will the typical user really care by default to adjust every axes in every​ font? Or will they typically only care for the axes explicitly flagged for their attention?

I think the latter is actually more true for the billions of people who use fonts daily in their typesetting but have little idea what typesetting or a font even is, if you asked them to explain it.

My recommendation is therefore the default be "show in expert modes", with flags for "show to every human" and "show to developers and people who really really care to see everything"

Peter Constable

Dave, what's the difference between "show in expert modes" and "show to developers and people who really care to see everything"?

Deleted Account

That covered the reason for recommended hidden axes then?

Laurence Penney

I’ve become unenthusiastic about the "UI suppression" flag. I believe it’s too early to introduce a new categorization for axes, orthogonal to that which already exists (registered/unregistered). The idea of explaining to a customer why they can’t see the slant axis in a font, even though it shows up for other fonts in the same app, seems absurd.

I think our genuine concern about axis overexposure may be based on our own overexposure to the *testing* interfaces of FontView, Axis-Praxis etc. on fonts that are pushing boundaries, where random axis values make them look awful. In *real* interfaces, such as that which Jason Pamental showed in his recent talk to Drupal developers (watch from 21:20 for 40 s), it’s probably a bad idea to show unregistered axes at all – leave that to those willing to dive in with CSS font-variation-settings, or to animate cycling lizards and dial up "x opaque weight" with JavaScript or Python.

Given the first real UIs for users will be on the web, where UIs and fonts can easily have a rapid test-deploy-revise cycle, these assumptions can all be tested by real app developers on real users and fonts. By the time desktop apps are ready to deploy, we will have the benefit of lots of web testing to decide how various kinds of apps should present various kinds of axes.

John Hudson

Laurence:

it’s probably a bad idea to show unregistered axes at all

I don't like the idea that axes need to be registered in order to show up in UIs, which is what this implies. I don't like it because I can imagine design-specific axes that very much require user interaction, and I don't like it because I can imagine the response from font developers being to try to register every axis they think of, at which point we're back where we are now.

Also, it seems arse-backwards to deny UI space to unregistered axes when the process of registering an axis is specifically to enable programmatic implementation of axes. Arguably, unregistered axes are precisely the ones that need user interaction rather than programmatic access.

I agree with your initial point:

The idea of explaining to a customer why they can’t see the slant axis in a font, even though it shows up for other fonts in the same app, seems absurd.

But this is why Peter has suggested that, for registered axes, the recommended flag settings should be stated with the axis specification. This seems sensible, and if some font developers decide to ignore those recommendations and e.g. hide an axis that most other fonts expose, they accept the responsibility to explain why to their customers. I would rather font developers have that option and that responsibility than for software to apply a procrustean solution without input from the font.

Axes define a design space. Ergo, the nature and purpose of particular axes is design-specific. That strongly suggests to me that the font needs to be able to provide suggestions to software makers about how the axes should be exposed, or not, in UIs.

Now, in my experience, software makers are protective of their UI space and don't like being told what to do with it — cf. lack of support for various OTL features in Office apps —, so suggestion is as far as we can go. The aim should be to define that suggestion in a way that software makers find useful, and hence want to implement. I'm concerned about the 'advanced' and 'expert' UI notions in this thread, because those are un-defined and subjective descriptors, and that's not helpful to software makers. But I think falling back on registered/unregistered distinction and giving up on the idea of design-specific font input is a worse idea. At the moment, Peter's proposal looks like a reasonable and workable — reasonably workable — middle-ground.

Dave Crossland

John Hudson said:

Laurence said:
it’s probably a bad idea to show unregistered axes at all

I don't like the idea that axes need to be registered in order to show up in UIs, which is what this implies.

I think it is very important to show some unregistered axes! (And not show some others, on a per font basis.)

I would even offer that "Registration" would be better called "Interoperable" because that is its purpose.

I must stress how important I think it is to see visibility-flagged and registered-for-interop as orthogonal issues. 

John Hudson said:
So you want are flags for 'Always show this', 'Sometimes show this', and 'Never show this'? The 'sometimes' criteria are unclear. What does 'advanced' UI actually mean, and who gets to decide? If a developer has a single UI paradigm, should this flag be interpreted as include or exclude the axis?

I am optimistic that the 'sometimes' criteria can become clear; but if it isn't, then it can be interpreted either as include or exclude, depending on the audience of the app; perhaps InDesign would veer to include and Word would veer to exclude. However, probably it should be specified to be the same as default ('no flags at all') choice..?

I believe a user should always be able to see all axes; but I have a clear sense of orders of magnitude different kinds of users. 

Peter Constable said:

Dave, what's the difference between "show in expert modes" and "show to developers and people who really care to see everything"?

The difference is between typographic experts - who know how to make things look just right - and developers/engineers - who know how to make things work. 

Its tempting to conceptualize of the experts sitting between the engineers on the right and the 'everyday users' on the left, in a spectrum of sophistication. But actually this is not a straight line, because the sophistication is of a different kind. 

That's why 3 levels of flagging are needed.

Dave Crossland

D Epar Ted said:
Axis should only be exposed in "advanced" UI. None yet...

Shouldn't that be, all the slides except those in the other 2 groups?

Laurence Penney said:

I’ve become unenthusiastic about the "UI suppression" flag. I believe it’s too early to introduce a new categorization for axes, orthogonal to that which already exists (registered/unregistered).

The idea of explaining to a customer why they can’t see the slant axis in a font, even though it shows up for other fonts in the same app, seems absurd.

(I assume you mean 'even though it shows up in other apps.')

The idea of explaining to a customer why they can’t see an axes flagged as for typographers/engineers, even though it shows up in other apps, seems entirely reasonable to me; it is this risk of upset users that incentivizes app developers to always offer a way to see all axes - and I recommend that the specification to state clearly that all apps ought to do this. 

I think John raises a key point here:

John Hudson said,
So you want are flags for 'Always show this', 'Sometimes show this', and 'Never show this'? The 'sometimes' criteria are unclear. What does 'advanced' UI actually mean, and who gets to decide? If a developer has a single UI paradigm, should this flag be interpreted as include or exclude the axis?

I am optimistic that the 'sometimes' criteria can become clear; but if it isn't, then it can be interpreted either as include or exclude, depending on the audience of the app; perhaps InDesign would veer to include and Word would veer to exclude. However, probably it should be specified to be the same as default ('no flags at all') choice..?

I believe a user should always be able to see all axes; but I have a clear sense of orders of magnitude different kinds of users. 

I think our genuine concern about axis overexposure may be based on our own overexposure to the *testing* interfaces of FontView, Axis-Praxis etc. on fonts that are pushing boundaries, where random axis values make them look awful.

I'm not concerned about landing in a awkward spot in a design space. Rather, my concern is that it is hard to "tune" a stack of 3+ sliders into a "harmonious chord", to use a guitar metaphor.

Given the first real UIs for users will be on the web, where UIs and fonts can easily have a rapid test-deploy-revise cycle, these assumptions can all be tested by real app developers on real users and fonts. By the time desktop apps are ready to deploy, we will have the benefit of lots of web testing to decide how various kinds of apps should present various kinds of axes.

I think desktop decisions are being made well in advance of when they deploy. The time to decide is now

Andrew Johnson

Hi all, throwing in my two cents here from what I’ve learned with Typeshift.

I also think it’s valuable to start introducing users to non registered axis in UI – anything less than that would be short-selling so much of the creative utility that variable fonts provide.

At the same time also realize that overwhelming people with a ton of controls is off-putting and some of it can be condensed.

Generally with UX and interfaces it’s pretty hard to draw a definitive line between standard vs. expert users because ‘expert’ varies so much between people – and even more so as they learn. It could also vary according to the goal of the font itself.

From a design tool standpoint more information is helpful. If there was some way to expose a ranking / group with an integer value (and maybe a label) you could set groupings and priorities. Flags for multiple levels would let you be more intelligent with how you offer additional functionality (maybe unlocked/shown based on licensing or use case) to users and collapse whole areas of the design space at a time.

John Hudson

Dave:

I must stress how important I think it is to see visibility-flagged and registered-for-interop as orthogonal issues. 

Amen.

I'm not concerned about landing in a awkward spot in a design space. Rather, my concern is that it is hard to "tune" a stack of 3+ sliders into a "harmonious chord", to use a guitar metaphor.

There's been some talk about meta-axes, which I think are a good idea. But that's also orthogonal to the UI visibility question (or, rather, presents different ways of addressing the question, which may be suitable for different fonts), and would require a much more complex and intensive level of spec work than defining a flag for existing axis types.

Laurence Penney

Dave Crossland said:

John Hudson said:

Laurence said:
it’s probably a bad idea to show unregistered axes at all

I don't like the idea that axes need to be registered in order to show up in UIs, which is what this implies.

I think it is very important to show some unregistered axes! (And not show some others, on a per font basis.)
…
That's why 3 levels of flagging are needed.

I should have added more context to “it’s probably a bad idea to show unregistered axes at all”. I was referring to the kind of simple UI shown in the CMS as demo’d by Jason. Here, weight and width axes are already going to blow minds (in a good way) and take some getting used to — to me it’s fine if that kind of app chooses to offer only weight and width adjustment.

That said, I am absolutely for all apps being encouraged to make all axes visible via an advanced pane or whatever. The thing that concerned me (past tense) is being a bit too nannyish at this early stage, suppressing axes because we fear they will befuddle people in a period which should involve maximizing high quality feedback from early adopters who like to understand the tech and dig around, even for the “programmatic” axes.

Me:
The idea of explaining to a customer why they can’t see the slant axis in a font, even though it shows up for other fonts in the same app, seems absurd.

Dave:
(I assume you mean 'even though it shows up in other apps.')

No, I meant a slant axis being visible in one font but suppressed in another, in the same app.

Dave:
I think desktop decisions are being made well in advance of when they deploy. The time to decide is now

This is an excellent point. A desktop OS cannot revise UI decisions like an individual website can

If Peter is concerned that wide adoption of variable fonts inside Microsoft and other OS companies depends on being able to suppress potentially confusing UI in certain fonts, then naturally I defer to his judgement.

Peter Constable

What I'm concerned about is that I know in the future there will be a desire for some differentiated treatment of variation axes in user interfaces. As soon as we create new APIs exposing variation axes, there will be font-picker/text-formatting user interfaces created that expose axes. But if we don't have anything in APIs from early on to clue developers in that some differentiation of axes may be needed, then we'll face cases in UIs are created to support 'that cool new font-variations thing' and then the developers will move on and not want to revisit the area for a long time. So, what I'm most concerned about is educating developers early on to pay attention to this space that's still evolving and that may require UIs to evolve with it.

John Hudson

Laurence:

The thing that concerned me (past tense) is being a bit too nannyish at this early stage, suppressing axes because we fear they will befuddle people...

and

If Peter is concerned that wide adoption of variable fonts inside Microsoft and other OS companies depends on being able to suppress potentially confusing UI in certain fonts...

Is that the motivation, though? My understanding is that there are fonts, and will doubtless be more, that contain axes that are not intended for direct user interaction, and there should be a means to prevent these from being exposed to the user. It isn't that such axes are confusing or befuddling, but that they've been designed for purposes other than direct user interaction.

Axes define design space. The assumption that axis = UI is flawed. Indeed, one can easily imagine a design space composed of multiple axes, none of which are exposed to users, and imagine a UI that provides ways of working in that design space that doesn't reflect the axes.

Laurence Penney

Regarding a font’s design space, I would argue that it’s a pity if an interested user is deprived of the ability to understand the design space well, because of hidden mechanisms.

On the other hand, I’m very impressed that Microsoft apps may well show unregistered axes by default, and accept that the axis-hiding bit is a reasonable way to control those axes for which an interactive slider is inappropriate for a user.

I have one final comment on the matter. There are strong use cases that an app designed for non-expert users, such as MS Word, should allow arbitrary axis positions in a font’s design space to be selected – for example creating a document template designed by an expert. Selecting instances involving hidden axes should at least be possible using numeric entry. I wonder if it could be reflected in the spec, that for an app to "support variable fonts", it should offer at least a numeric method of controlling all axes. (For a web app, this could be as simple as allowing font-variation-settings to be added to the CSS.)

Dave Crossland

Andrew Johnson said:

From a design tool standpoint more information is helpful.

100% agree. A more complex and intensive level of spec work that goes beyond 1 or 2 flags seems inevitable...  

A long time ago, I had suggested to D Epar Ted that the information he'd suggested to be specified in EPAR tables would be much better if kept on a central metadata server, similar to www.musicbrainz.org

I suspect that this may be a good way to develop a range of metadata needed for VF fonts, including the "finer" distinction between the "everyday" and "typographer" classes of users, and perhaps in v1.9+ or beyond these could be made interoperable. 

To mitigate the oncoming slider-pocalypse, the minimum seems to be a single flag - 2 states, "off" and "on" - that indicates which axes should only be displayed to users when users enable a 'see all axes' mode. 

The remaining question that poses is which state should be default. Should all axes be displayed except those the font make says 'if you are advanced, check it out'? Or should all axes not be displayed except those that the font maker says 'you definitely want to see this!'

Adam Twardoch

All in all, I'm very much in favor of Peter's original suggestion of making a simple suppressFromUserInterfaces flag.

Please note that this flag will only be used in “advanced UIs”, because there will be no such thing as “simple UIs for axes”. Font-related UIs that expose any axes directly are already advanced.

“Simple UIs” that deal with font selection and formatting will:
1. Either allow just named instances through conventional means (i.e. a dropdown list of some sort or any such way to choose from a premade selection)
2. Or will hook up some axes into higher-level concepts.

For example, the proposed CSS4 linkage of the CSS font-weight property to the wght axis is the “simple UI”. In this approach, the user doesn’t care about an “axis”, she just cares about “weight”. There may be several ways to actually choose the font asset of a given weight, either from a list of fonts, or from the wght axis in one font, but the user just chooses “weight”, somehow. Similarly, tying the opsz to the user-selectable font size is the “simple UI”.

Any UI which will actually expose font variation axes is already “advanced”. I do agree with Peter that the flag should work as “suppress”, i.e. the default assumption would be to show axes, and the flag should be a “hint” for the UI developer that she may choose to ignore. With the suppressFromUserInterfaces flag being set, the UI designer may choose not to provide a user interface for that axis. This may be useful for some scenarios, especially if the axes are already used by some other mechanisms, i.e. they’re more of a programmatic nature. For example, the community may at some point agree at a “gamma axis” intended to set the “gamma” of all type in a document using some simple preference, possibly even on the OS level. This type of setting would not be useful if the user overrides it individually. 

The final step is low-level access to all of the axes, like via the font-variation-settings property, which is should be thought of as being similar to a programmatic API rather than being a “user interface”. I don't think we'll ever want to exclude any axes, because... font developers won't be able to test any font if all access to axes is blocked.  

Of course the idea is that if an axis is suppressed from the UI, it is still used somehow differently, but in a more automatic way. This is similar to how many OpenType Layout features are “suppressed from the UI”, e.g. you typically don’t have a checkbox for the kern feature or the ccmp feature, because that’s supposed to be enabled by the shaper. Same goes from many features for complex scripts. Even though we don’t yet have any shapers that rely on “programmatic axes”, but they may show up. It’s good to have this mechanism in the spec already. 

I'm fine with Peter's original wording: “suppressFromUserInterfaces” = “The axis should not normally be exposed directly in user interfaces”, and I’m fine with any clarifying edits he chooses to provide. 

Adam Twardoch

Also, please think of UIs as not just checkboxes in a desktop app.

Think for example about webfont services such as webfonts.fonts.com, MyFonts or Google Fonts. 

They may expose certain axes to users but may use some axes “magically” server-side. For example, the “gamma” axis I mentioned could be one that the webfont service chooses to balance the darkness of type across various devices. If such a webfont service provides some simple UI for web designers to choose instances from the variation spectrum, the service would only perhaps want to expose the “unhidden” axes, while still using the hidden axis in some smart programmatic way. 

Adam Twardoch

Another aspect where the "suppressFromUserInterfaces" is "release stability". Font developers may provide the "suppressFromUserInterfaces" flag for axes that they have implemented in a font they release, but where they intend the axis to be used only via some programmatic API calls, and they don’t “guarantee” that the axis will stay there in future versions of the font, or that it will behave in the same way.

This is similar to how “public APIs” and “private APIs” are used in programming. “Private APIs” are often “hidden” from public documentation, and other developers are discouraged from heavily relying on them because those “may change in future without warning”. 

The suppressed axes would still be available through lower-level techniques, but would be not shown in more popular apps aimed at larger user bases. If the large user base of “normal” users invests in documents set in variable fonts, they will expect some stability between font versions. Since settings on the “public axes” (the ones without the suppressFromUserInterfaces flag set) will be used by more users to design their documents, the users will probably expect that the scales or behaviors associated with those public axes won’t change, and if they will, then the font will clearly signify that (e.g. by changing its name).

But “private axes” (the ones with the suppressFromUserInterfaces flag) can be more flexible — they can change more often between releases, and, being equivalent to private APIs, the users who choose to use them should take into account that if they do choose to use them, their documents may change if a new version of the font becomes available. 

Jason Pamental

Thanks for mentioning the talk Laurence, and bringing this thread to my attention!

The goal I had in putting together that demo was based on my thinking that we need to support an 'expert mode' in our web tools, much in the way that we have designers involved to lay out a printed publication. They may not be right for everyone, but I think it's important to think through how it can work for 'everyday' (with perhaps just weight and width) and how it can work for 'experts' (exposing all those axes that 'should' be user-accessible).

After looking through the discussion here I do get the notion of 'some axes are not meant for user setting', but beyond that I do think it should be up to the tool maker to decide if they want to limit what's available, or set up an 'easy/expert' mode.

In many cases the appropriate axes to expose might be better mapped to specific combinations like 'light condensed' (in which case drop-down or radio button or some such convention might be appropriate) but the opportunity is to create the 'expert mode' that can be leveraged by more experienced designers to actually typeset a specific headline or block of text, rather than live with a system that is designed for all content but optimized for none.

Don't get me wrong: I still think we need to have well-designed typographic systems for any website, but this possibility to extend the design system using tools like this right in the place where the content lives is pretty exciting.

I'm trying to work through a more universal approach that could apply to/be incorporated into any web-based system and think it's coming along pretty well.

John Hudson

Jason:

After looking through the discussion here I do get the notion of 'some axes are not meant for user setting', but beyond that I do think it should be up to the tool maker to decide if they want to limit what's available, or set up an 'easy/expert' mode.

It's always going to be up to the software developer responsible for the UI, which is why the font flag only provides a suggestion.

I agree with Peter's idea that registering a single flag now serves the purpose of informing software developers that they need to consider UI for variable fonts, and be aware that exposing axes isn't an all-or-nothing choice. I think the registering of additional flags should involve discussion with software makers, and we should be asking them 'What kind of information in the font would be helpful to you in building variable font UIs?' At the moment, we're mostly guessing about that, and it seems premature to do more than signal that some axes are intended only for programmatic use and should not normally be exposed for direct user control.