[CREATE] Typographic feature UI/UX

Nathan Willis nwillis at glyphography.com
Thu Nov 20 13:24:01 PST 2014


There's an interesting discussion going on in the type-design
community at the moment that I think a number of FOSS projects might
be interested in.

The issue is how applications expose (or fail to expose...) the font
features available in a selected font to the user. This is "features"
in the sense of optional functionality built into the font itself:
small-capitals, variant forms of glyphs (individually, like swash
caps, or in sets), lining or tabular numeral options, extra ligatures,
that sort of thing.

All those are things that the font designer can create pretty easily,
technically speaking -- good software support across the board, and
OpenType files have standardized the formats that the features are
encoded in -- but, in order to be of real use, it's the design
applications that have to recognize them and provide a usable
interface to.

For instance, if somebody is creating an ad or sign (in, e.g., GIMP or
Scribus); ideally they could
  (a) find out easily that their selected font has some optional
features that might apply to their work,
  (b) try out the features without much trouble.

They may also
  (c) have some feature in mind and want to figure out which, if any,
of their installed fonts support it.

Thing is, proprietary design apps do a terrible job on all counts of
this. So much so that at this past month's annual ATypI conference
there was a spontaneous speech from the audience on the subject during
one of the panel discussions, and they eventually started an online
petition to provoke Adobe to do something about it in Adobe Creative
Suite: http://ilovetypography.com/2014/10/22/better-ui-for-better-typography-adobe-petition/

I don't know what the odds are that Adobe is actually going to respond
to it, but there doesn't seem to be much movement.  ANYWAY, to get to
the point: free-software design apps don't really do a better job.
So, (a) there's an opportunity here to do something useful, but just
as importantly, (b) there's a knowledgeable community discussing what
the right interface to this sort of feature should be, so that's worth
listening to.

There's a blog post that shows what recent Adobe UI designs are like:
http://ilovetypography.com/2014/10/25/why-a-better-opentype-user-interface-matters/
-- spoiler: it's a big hierarchy of nested context menus.

There have also been some experiments in mocking up what folks think
would be a more useful approach:

- https://klim.co.nz/blog/towards-an-ideal-opentype-user-interface/
- https://medium.com/@CommandZed/thoughts-on-an-improved-opentype-ui-c6748f2eef3a


So I'm curious (1) if anyone else is interested in this topic, (2) if
anyone has worked on it already, and (3) if anyone is interested in
pursuing it further. It does seem like something it would be worth
collaborating on a common approach to (generally speaking, I mean),
hence my bringing it up here.

Implementation difficulty I'm not going to hesitate a guess at; that
probably varies a lot. But even if not every application project is
interested is working on it anytime soon, thinking about it is
probably good, and you never know -- it could make for a project
someone else would like to tackle down the road.

Thanks,
Nate


More information about the CREATE mailing list