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.
3
Comments
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.
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.
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.
- 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?
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.
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 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.
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 loop button, with default state
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.
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.
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.
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.
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"
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.
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:
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.
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.
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.
Axis should only be exposed in "advanced" UI. None yet...
Shouldn't that be, all the slides except those in the other 2 groups?
(I assume you mean 'even though it shows up in other apps.')
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 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.
Amen.
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.
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.
(I assume you mean 'even though it shows up in other apps.')
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.
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.
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.)
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!'
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.
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.
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.
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.
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.