A List Apart considers user interfaces for variable fonts

Marc Oxborrow
Marc Oxborrow Posts: 220
edited November 2017 in Font Technology
User Interfaces for Variable Fonts, by Andrew Johnson
Tagged:

Comments

  • Johannes Neumeier
    Johannes Neumeier Posts: 377
    I remember a time when every A List Apart article would leave me mind-blown... articles like this, however, that do not really provide insight, solutions or inspiration and are somewhat lackluster. The article comes across as someone's self-marketing write-up bolstering their own person-brand, reviewing more or less related interface approaches for multidimensional axis manipulation without any thoughtful conclusion, or in the authors closing words:
    This gives us a unique opportunity to further typographic creativity and utility.
  • Andrew Johnson
    Andrew Johnson Posts: 14
    Hi Johannes / George, I wrote that article (along with this previous one on interpolation) – thanks for the feedback! Really sorry it came off that way.

    My intent was to pull the conversation away from talking about individual pieces of UI (sliders vs. no sliders) and broaden things to show more hybrid approaches like macro controls. I hope UI will adapt to the fonts themselves – similar to how game engines like Unity have a customizable inspector.

    Also made no attempt at 'solving' UI for variable fonts – something like this needs to be community driven (and will inevitably be product driven). If the article can help type / web designers get a better, more holistic view of possible variable font UI i’ll be happy. Know a great deal of people have been thinking about these problems for a lot longer than I have.

    If you have any ideas on how to improve something like this please email me, would love to make it better!
  • Johannes Neumeier
    Johannes Neumeier Posts: 377
    There's nothing wrong with sparking conversation and mapping out possible solutions and drawing inspiration from other fields that face similar UI problems. As such, I applaud you for writing the article and A List Apart for publishing it.

    What I disliked is more sparked by A List Apart's editorial stance, and not you personally or your article. More and more it is "A List of ... commentary pieces and op-ed contributions" much like a Medium subtopic, when it used to be a online bible of nifty solutions and ground breaking implementations for new tech. I appreciate that design is a more messy subject with less clear-cut solutions, and they have ventured more into that area for some while now. I for one have come to miss the old A List Apart now and then, and my comment was just as much expression of that.

    As for some actual discussion of Variable Font UI's, the biggest problem I see is that people seem to get carried away thinking about how to solve the multi-dimension problem, and lose sight of visualising something that is intuitive and clear. That level of abstract thinking is hard to apply to the parameters of a typeface for more than one dimension at a time. Trackpads, "rgb"-like fields, and the like, in my opinion they are all too abstract to really navigate that design space with any confidence (as opposed to sliding around to find what looks more or less acceptable). From where I see it, any standardised solution will eventually boil down to one control for each design axis - and why wouldn't it be simple stupid?
  • Mark Simonson
    Mark Simonson Posts: 1,734
    I think a practical solution might be something like the Adjustments interface in Apple Photos (and previously in Aperture), where a basic set of sliders is displayed by default, but other available sliders may be added if desired via a pop-up menu.
  • Hrant Հրանդ Փափազեան Papazian
    Hrant Հրանդ Փափազեան Papazian Posts: 2,044
    edited September 2017
    BTW if we want to leave room extrapolation, we need a slider that's linear between the most extreme defined points, and exponential beyond them.
  • Ray Larabie
    Ray Larabie Posts: 1,432
    Let the user fondle the typeface.


  • Deleted Account
    Deleted Account Posts: 739
    Peter:;“E.g., one could imagine a font that doesn't have an optical size axis, but does have contrast, x-height,....”

    It’s been demonstrated. Those is are not registered axes though, so forget mixing, much less saving a user’s opsz. And without the selection mantra officially registered either, good luck with Ui intelligence. Most users also understand primary and secondary colors, and colors are easier to sample and compare than type, because they are not defined relatively by the artist or color company, like the current OT spec mostly ignores actual typographic parameters. In addition, color does not get bent out of shape by OS and apps making up their own laws to govern its appearance, or by their adoption of rendering that makes some colors easy, and other colors nearly impossible to use.

    You are probably right though, all this has to be done, done Right, and not just for Latin colors. Good luck!
  • John Hudson
    John Hudson Posts: 3,190
    edited September 2017
    Peter:

    Another 2D control that is fairly common is the level-curves control used in image editing apps. The concepts involved are more abstract, and therefore the level-curves actually have a fairly significant learning curve (pun intended). To the extent these controls are successful, it is because the problem to solve can only be controlled in two dimensions: the need is to set level adjustments for pixels of various luminance levels, spanning the complete range of possible luminance levels -- so a continuous range of input luminance levels needs to be associated with an adjustment value for each. 

    As you say, there's a significant learning curve involved in understanding how level-curves controls in image editing apps work, and in being able to use them to achieve the results one wants. They're an example of what I would consider and advanced UI, intended for image editing professionals or highly committed hobbyist photographers. In addition to needing to understand how to use these UIs to achieve a particular result, a user also has to have a pretty good idea of what result she is trying to achieve.

    Meanwhile, when I take a photograph with my iPhone, the first thing I do when I open the built in editing tool is to click the little magic wand icon, which does something to some values in an effort to improve the image. I decide whether I like what it has done or not, more than the original state of the image. Then, if I want, I can progress to a secondary level of UI in which I can apply from a number of pre-set filters. Then I can progress to a tertiary UI level in which I can perform adjustments to some global parameters e.g. make the image darker or lighter, which is actually adjusting both brightness and contrast and probably some other values together. This is the first time anywhere in the UI that I encounter a kind of slider, although in this case it is presented as a scroll of lighter and darker thumbnails of the image. And finally, I can proceed to the advanced, quaternary UI level of sliders for adjusting individual values.

    I don't doubt that there will be sliders somewhere, at some level of UI control for variable fonts, and numeric inputs for precise values, and advanced users will want any may sometimes actually need to directly adjust individual values along variable font axes. But unless we're going to insist on a significant learning curve for variable font typography that effectively excludes large numbers of users— and bearing mind how few nominal design professionals have bothered to figure out how to use existing, fairly simple OpenType Layout UI —, that level of UI doesn't seem to me the place to start.

    Instead, maybe we should be asking 'What is the typographic equivalent of the tertiary level of image editing, i.e. of making global parameter adjustments?' — towards which I think Peter's question about which axes to group leads. But also, 'What is the typographic equivalent of pre-set filters?' — is it just named instances in the individual font, or could it be a higher level understanding of kinds of text? And even 'What is the typographic equivalent of the magic wand, a "Make this text better" button?'
  • John Hudson
    John Hudson Posts: 3,190
    Hrant:

    BTW if we want to leave room [for] extrapolation, we need a slider that's linear between the most extreme defined points, and exponential beyond them.

    While it's possible that software could apply extrapolation beyond axis extreme delta sets in variable fonts, that sort of extrapolation is not part of OpenType variations technology. [Mathematically, interpolation of design space locations between axes is a form of extrapolation, but I've avoided using the term when discussing variable fonts, because people tend to associate extrapolation with extrapolating beyond the extremes of an axis, i.e. of going outside the design space.]

    The design space of a variable font is a bounded space within which a variety of kinds and scales of shape interpolation, positioning interpolation, interjection and intersection may be applied. It isn't even clear to me what variable font extrapolation outside that design space would even mean in terms of many of those things, except crude extrapolation of the last known trajectory of point interpolation. Everything that makes OT variable font technology powerful and programmatically useful would get left behind in the design space.
  • Dave Crossland
    Dave Crossland Posts: 1,429
    'What is the typographic equivalent of the magic wand, a "Make this text better" button?'
    Sounds like we need a standardized/registered set of 'lower level' axis that are used in concert to 'construct' or 'blend' the 'higher level' axes that are already registered... like https://variationsguide.typenetwork.com :)
  • John Hudson
    John Hudson Posts: 3,190
    edited September 2017
    Dave,

    If you're taking as 'higher level' the five axes that are already registered, what's the mapping of lower level programmatic axes to those higher level registered axes? Where is this mapping expressed? At the font level, or somewhere else?

    Is there a clean n:1 relationship of particular programmatic axes to an individual higher level registered axis? Or can a single programmatic axis be affected by multiple higher level axes? Or is there, in fact, the possibility of n:n relationship between particular programmatic axes and particular higher level axes? And, again, where is this expressed?

    At the moment, we've got no standard model in which there are 'higher level' axes and 'lower level' axes. We have recently added a flag to indicate that a given axis is not normally expected to be exposed in UIs, but that's a long way from defining an implementation spec for how programmatic axes relate to higher level axes.

    At the moment, the idea of higher and lower level axes is purely conceptual: there are just fvar axes, with defined mathematical relationships in variation space, and a flag that says some of them will probably be hidden from users most of the time. Personally, I'm not sure that the distinction between lower level controls and higher level controls belongs within the framework of the font axes. It seems akin to another faulty idea in OpenType Layout that never worked: the idea expressed in the original fraction and optical bounds models that one layout feature would apply other layout features, without there ever being a data model in which that was possible. It may make much more sense for true higher level controls, i.e. at app or API level, to directly access programmatic variation axes and bypass nominal axes for that functionality completely. So, for instance, if the correct optical size typeform for a given text setting is derived from adjustment to programmatic axes for stem weight, counter width, x-height, and spacing, you don't need an Optical Size axis at all. In either case, what you do need is a way to map from the programmatic axes to the higher level control, whether that's directly or via other axes.

    I am also wary of using the same data tags for different things, of having a registered axis like Weight that in some fonts is an axis directly accessing point deltas in the design space and in other fonts is affecting other, lower level axes.

    LET ME BE VERY CLEAR ABOUT SOMETHING : I like the idea of programmatic axes and being able to make very flexible variable fonts that are machines for generating tuned typefaces. It is a Really Good Idea.

    But it's not the idea that has so far been built into the OpenType variations technology, and if we agree that it is an idea that should be implemented, then we need to go back to the working group and do a bunch more work. My inclination is that such work would inevitably result in two different kinds of variable font: ones that use fairly high level axes to affect variations in outline design akin to existing multiple members of a static font family (indeed, in many cases built directly from the sources for such families), and ones that use programmatic axes to affect variation of isolated characteristics such as stem weight, x-height, ascender height, etc... What seems to me unlikely to be possible, if we want predictable behaviour, is any free hybridisation of the two, so the spec will need to define either the wall between the two or some very tightly controlled ways in which the axes for each model are allowed to interact.

    That's all doable, but simply registering a lot of lower level programmatic axes within the existing fvar framework doesn't get us there. As I pointed out before, in the late 90s Adobe and Microsoft registered a lot of OTL features that they thought might be useful, and failed to do the work of writing an OTL implementation spec. I don't want to see the same thing happen again with variations axes.
  • Simon Cozens
    Simon Cozens Posts: 741
    I just drafted a very long post and re-read it only to discover it was saying essentially what John said above. So I'll extract one idea from it: what programs the programmatic axes, and what do those programmes look like? Let's suppose we have three "back-end" axes - stem weight, width and x-height - and one front end "weight" axis. Is it enough to make the relationship between these into a table of linear interpolations between two (or more) bounds:

    Weight    Stem weight    Width      X-height
    10050500750
    900150700780

    I initially thought it would not be good enough, but I am now unsure. It might actually work.

    This of course assumes we have a separation between back-end and front-end axes. Thinking about the "magic wand" and the degrees of UI complexity idea, I might want the ability to set n parameters in the UI and have the values of the other axes optimally determined: as I increase stem weight, x-height also increases. When I tell the computer that I want to set stem weight and x-height, width gets adjusted. So each axis can have a value either between minValue and maxValue or be specifically unset, at which point it is determined programatically from the values of the axes that are set. This gets away from the "back-end"/"front-end" distinction but it makes the representation of the relationship between axes stored in the font more complex.

Categories