“Adobe InDesign is a desktop publishing software application produced by Adobe Systems.” It is used by professional graphic designers and typographers on a daily basis. It does many things well, but it does not provide a good OpenType feature user interface. What it does provide is, in fact, abysmal. This has frustrated many of us over the years.

This frustration has recently come to a head with the I Love Typography Better UI for Better Typography petition reaching over 1,300 signatures. Yves Peters has also written an excellent summary of the situation, explaining why a better OpenType user interface matters.

I like InDesign. I think it’s a good application. However, as a maker and seller of fonts, it pains me that a poor interface hinders and obfuscates the OpenType features I build into my fonts. I am certain all other type foundries feel the same. I would love InDesign — and all OpenType-savvy apps — to honour and respect the work we put into our fonts. This also means respecting the user, whether she be a student or professional.

Gerry Leonidas says “prototyping the proposed interface will need to be done in an app-agnostic way, and from a document designer perspective.” He’s absolutely right. My proposals are therefore not limited to InDesign. Anyone is free to steal these ideas.

There are three critical questions an OpenType UI should answer:

1. What are the OpenType features in this font? Users shouldn’t be expected to remember which fonts have which features. The application UI should be clear and helpful.
2. How do I apply the OpenType features? There are often several ways to apply a feature, not all of them are intuitive or easy to find.
3. Where have the OpenType features been applied? It’s important to know where features have been applied, sometimes it’s not entirely obvious at a glance. For example, a fraction can either be created by either an OpenType feature or inserted by an explicit keystroke.

OpenType features are binary, they’re either on or off. More than one feature can be applied to text, and some features override others. For example, Small Caps and Stylistic Sets can be applied at the same time, or Old-Style Figures and Fractions. The order in which they activate is determined by the font designer. For example, Small Caps should override Ligatures, otherwise small-capped words like “conflated” would not look as expected.

There are three states an OpenType feature can be on a selected piece of text:

1. No OpenType Feature active.
2. OpenType Feature active in some of the selected text.
3. OpenType Feature active in all of the selected text.

However, an OpenType feature can be active in selected text, but may not cause any visible effect. For example, the word “International” may have the Ligatures feature applied, but there are no “ffi” combinations so there will be no apparent effect of the feature to the text. There are two possibilities for feature availability in selected text:

1. OpenType Feature is available for the selected text.
2. OpenType Feature is unavailable for the selected text.

I therefore propose the following UI behaviours.

This is a basic overview showing the various combinations of OpenType states and availability in the UI. “International Office” is text in a page layout app, the blue box represents text-selection. The grey box represents an OpenType feature panel for the app. In this example the font only has one feature, a Common Ligature: “ffi”.

The OpenType feature is available but inactive in the selection.

The OpenType feature is unavailable and inactive in the selection.

The OpenType feature is available and active in the selection.

The OpenType feature is unavailable but active in the selection.

The OpenType feature is available and active in some of the selection. In this case, the feature is active for “Office” but not “International”

This is an example of the UI for a fully-featured OpenType font, Adobe’s Minion Pro. A paragraph with some OpenType features activated has been selected. It follows the basic logic of the first examples. Here I would like to introduce two rules for the proposed OpenType panel.

1. The OpenType panel/palette must be persistent. Multi-level drill-down “flyout” menus are painful and lazy.

2. The OpenType panel/palette must be dynamic. Show only features supported in the selected font. Showing features that are not supported is dishonest and confusing.

The proposed UI follows the two rules above, and answers the initial critical questions 1 and 2.

Here is a proposal for critical question 3: Where have the OpenType features been applied? This again uses the basic example from above. The functionality is similar to find/replace interfaces in text editing applications. In this example, the font only has one active OpenType feature, a Common Ligature: “ffi”.

The OpenType panel indicates the selected text has a feature activated. Hovering over the “Common Ligatures” line reveals a pair of left/right arrows.

Clicking the right arrow jumps the selection to the activated Common Ligature “ffi”. In a small 2-word selection this functionality might not be necessary.

Another option is a simple show/hide icon. In this example, when the eye icon is clicked all instances of the active OpenType feature are highlighted.

This option would be very useful for large text blocks over multiple pages. The user can quickly identify activated OpenType features.

This a more radical proposal. I imagine this to be useful for single words like logotypes, and short phrases like headlines. It makes display typography easier to create. It covers all three critical questions in one shot. It would probably have to be a separate UI panel, it’s cumbersome for large text selections.

The OpenType panel indicates the selected text has a several features available, and two are activated. The panel dynamically displays the selected text in grey. The black text indicates what the OpenType feature will activate when the checkbox is ticked.

1. Don’t use icons to represent OpenType features. Use plain language. The current Photoshop OpenType icons, for example, are ambiguous and fiddly. Furthermore, there is no broad consensus in the industry about which icon represents which OpenType feature.
2. If your application allows an “eyedropper” tool for text, this should also apply the OpenType features.
3. Separate basic typography controls and transformations from OpenType features. It’s confusing for the user if they’re mixed together.
4. Be honest about what a menu option does. Clearly indicate the difference between activating true OpenType Features and typographic transformations. For example, if you must offer faux Small Caps, Superscripts and Subscripts as an option, call them “faux”.

The issue isn’t that faux Small Caps are an option. The issue is that it is dishonest. InDesign, for example, offers the option of Small Caps even if the selected font doesn’t have them. If the font doesn’t have proper Small Caps, InDesign simply scales down the capitals. It’s a con, and should be removed or fixed. There is no shame in using faux Small Caps, but it’s shameful to obfuscate the menu option.