Font impoverished

Over the past few months I've found myself confronted by an unexpected problem: the lack of a functioning platform and ecosystem for using custom fonts in applications. I'd assumed this problem had been solved long ago, but practical experience suggests otherwise, as does the the world of extant UI out there. Something like 99% of the client UIs seem to use a stock system font, and 95% of all the real text in web pages seems to be set in a standard sans serif font (Arial or Helvetica). I've come to view this as one of the tightest practical constraints on UI expression today.

User experiences suffer from this bland uniformity, as does an organization's ability to reinforce its identity. Type is such an important part of establishing brand. No one designs printed material without careful consideration of typography, yet we put up with only tiny amounts of custom type on web pages and in applications—and this text is inevitably hardcoded as images where it can't do as much good. To me this is akin to the color limitations of yesteryear.

16 colors: Limited, boring, lame

Stock sans serif font: Limited, boring, lame

Here are just some highlights from the catalogue of pain accompanying attempts to use a custom font in a user interface:

Lack of decent development support for rich text. On most client UI platforms, if you want to display static text, you use a simple label control. This label control can generally display a block of text in a single typeface, point size, weight, and style. There's generally no support for simple inline changes like this that apply to a span within the text; text properties always affect the entire text block. This leads to a general apathy towards typography that pervades the entire development experience: since doing anything interesting is hard, why bother? There's generally no support for styling, so evolving a user interface that uses anything but the system font becomes a tedious exercise in tracking down font references and making sure that every obscure dialog is using your fonts the right way. Most platforms include a rich text control, but these are meant for run-time editing, not design-time editing, and their performance is usually terrible. Alternatively, you could host your text in a browser control, which has an even worse design-time experience, even worse performance, and complicates your development substantially as you have to factor text into tiny fragments of HTML.

Licensing minefield. Oh, you thought you could just give away that font with your app, huh? That font file is intellectual property that you need to pay for, and licensing anything can be a legal nightmare. Designers at large software companies can call in airstrikes from their legal department to have licensing agreements negotiated on their behalf. Startup folk have to do this on their own, and what a royal pain it is.

Font foundries are focused on graphic designers. A graphic designer usually needs one copy of a font for their own use. They create something in Photoshop or whatever with the font, then create the desired physical (print) or electronic rasterized output (PDF, etc.). Approaching a company like this with a request to include their font in your application or site will get you the email equivalent of a blank stare. I spent an entire morning on the phone with one of the largest font vendors on the planet trying to find someone who could license one of the company's fonts to me. I was transferred seven times to different people, none of whom had the faintest idea was I wasking for. One person asked me whether my application would be used by more than 5 people. The company's web site was no help—in fact, it was misleading and therefore worse than useless. Whever a company has this much trouble accepting money from someone desperate to do the right thing and pay them, something is seriously wrong.

Installation hassles. For Microsoft Windows, at least, support for custom fonts remains the same as it has for years: you can only reference fonts that installed in system's Fonts folder. This means that your Setup program has to physically copy the required font files to the user's PC. The copied fonts are loose font files that the user can then use themselves. This is Lame with a capital "L", particularly because it compounds your licensing nightmares (above). Why on earth should you have to pay to give all your customers the ability to use a font in their own documents just because you want to use it in your app's UI? You don't have to give your customers loose copies of your audio files, or image files, or videos, or any other type of resource. Recent experience has convinced me that installing fonts on Windows is a fragile and buggy proposition. Even with the substantial assistance of a widely-used setup framework, it's absurdly difficult to ensure that the fonts you want get registered in such a way that they can be used immediately (without requiring a reboot) under all conditions. Other OSes may fare better here, but given the problems I've witnessed in Windows, it's no big surprise that most Windows ISVs punt and stick with Tahoma.

Web limitations. Web sites that want to use custom fonts can resort to what can only be described as hacks. You can use Microsoft's WEFT (Web Embedding Fonts Tool) if you want to limit yourself to Internet Explorer and sign up for a bunch of deployment hassle. You could also look at tricks like sIFR that (amazingly) work but involve gyrations with scripting and Flash. Isn't it odd that it's easier to make text blink than it is to format that same text in a font that is part of your organization's visual identity? One can infer that the small number of sites using any of these hacks is a reasonable indiciator that the problem remains unsolved.

Flash is a bright spot here, giving designers the choice of embedding fonts or referencing installed fonts. Unfortunately, for a variety of reasons, I don't find Flash a viable option for mainstream application development. If you're someone who gets to use Flash, I envy you your freedom of typographic expression.

Given the pace of change, I'm sure this problem will eventually be fixed. In a few years we'll look back at screen shots of client apps or web pages from this time and instantly recognize them as dating from an earlier era—because most of the text will be formatted in the same stupid sans serif fonts.

Comments

[Sam]

I wonder if this will get better in Microsofts next dev platform WPF/Avalon.

[Ian Griffiths]

Actually Windows has supported 'private' (process-local) fonts since Windows 2000. See the AddFontResourceEx API.

PowerPoint seems to exploit this. It's possible to bundle a font into a PPT file so that you can view the presentation with the fonts the designer intended without having to have those fonts installed on your system.

To reply to 'Sam' above, yes WPF improves matters - it provides decent support for rich text just as Jan describes. Also, the XPS packaging format (a WPF technology) is designed to allow fonts to be embedded. Just as with PowerPoint (and PDF for that matter) this embedding is designed to let you view the document with the proper fonts without having to install those fonts.

[David Dunham]

We included a font with King of Dragon Pass, which ran under Windows 95 (and Mac OS). IIRC, we would have been able to license something from Bitstream, but we ended up creating our own font so we could get the same bits on the screen for both Mac and Windows.

[Jan Miksovsky]

Ian: Thanks for the pointer to AddFontResourceEx.

[Ruben]

Add to this Microsoft's refusal to properly support Postscript-based fonts (Type 1 or OpenType/CFF). You know: the dominant font formats used by professionals.

GDI-based apps are in the clear, but Cleartype is definately a big no-no for Type 1 and OpenType/CFF. And no Opentype features, you'll need to do that by yourself.

WPF is has more fancy rendering and actual Opentype support. But no Type 1. I mean, seriously?

GDI+/.NET apps (Visio anyone?) are left in the cold completely: no Type 1 or OpenType support at all. Buggy. And horrific letterspacing, cramming letters together when your line becomes longer than five words until they even start to overlap. And no typography support at all (kerning, letterspacing, ligatures, complex scripts, you know: the basics). Oh, did I mention that it's buggy?

With all this crappy font support, why even try?

[Ed]

"User experiences suffer from this bland uniformity."

No. Wrong, wrong, wrong. Users don't complain about "bland uniformity", not at all, not ever. Never. Am I clear? They. Don't. Care.

They want to make the program do what they want it to. That is what they want. They want to accomplish the task at hand as painlessly as possible.

User experiences suffer from unreadable text. Normal users don't care if the UI is "bland" (have you taken a look at Mac sales figures lately?). The novelty of "exciting" UIs wears off in two minutes and then they have to USE it.

Text is readable if it is in a dark color on a light background, with adequate contrast between the two and very little saturation in either. The font must also be LARGE ENOUGH TO READ, hear me? And the font shouldn't be overly busy or decorative, and the letter-spacing should be sufficient. As long as sans-serif fonts have existed (a couple of centuries IIRC), they been understood to be unsuitable for "body text" (old-school typographers have been usability-oriented since the 15th century). At screen resolution serif fonts aren't so fantastic either, to be fair, but they're still better than sans-serif

None of this is news. Nor is it controversial.

But it's news to this knucklehead with a blog here. Lectures on "UI design craft" from somebody who can't even design a readable web page. Hey, why not get one of those animated rotating-pencil gifs? And some of those rainbow-hbars? Maybe a twinkling-star background gif, how's that sound?

Graphic designers should stay away from UI design. With very few exceptions, they're incredibly bad at it. They don't GET it, and damned few of them ever will: A UI is not art. It's a tool. It is not an end in itself. It is a means to some *other* end. I repeat: IT'S NOT ART. IT'S A TOOL. Usability is indispensible. A strikingly original, gorgeously slick-looking design that can't be used has exactly zero value. A "bland" interface that helps you get things done is worth a lot.

In fact, that strikingly original, gorgeously slick-looking design is aggressively subtracting value, becausue it is distracting. All those positive-sounding adjectives mean it calls attention to itself -- when you'd rather be dealing with whatever you're working on. It's all about itself, not about getting YOUR work done. It is designed with a purpose that is, in practice, at best indifferent to the user and more often actively hostile. No, thanks.

What user ever sat there gazing adoringly at a GUI? Nobody. It'll never happen. You're not Modiglifuckingani here.

So take your snazzy fonts and go to hell. First, computers empowered ordinary users to create their own documents: The result is howling nightmare of ransom-note typography and general loathsomeness. And *&^#(*#^^ POWERPOINT for God's sake. Now you want to inflict the same garbage on us in UIs? GO AWAY. JUST GO AWAY. LEAVE US IN PEACE. WE HAVE WORK TO DO.

[Scott]

I have to agree with Ed. I always disable "allow web pages to change fonts" because there are too many designers who think that 4pt Comic Sans is a great body text font. Then you go to a different website where they think 26 point Zapf Chancery is the right thing.

I'm happy to never, ever, EVER have anyone choose a font for me and use a boring, readable font until the day I die.

Exceptions? 1. Games; 2. Headlines. Fine; use PNGs there.

[James Schend]

Mac OS Classic (1.0-9.2.2) had a way to embed fonts in an application without allowing any other applications to use them using the resource fork. Unfortunately, I'm pretty sure this is no longer supported in OS X.

[Mat Hall]

I'm also with Ed on this -- fancy fonts and stuff in a UI is only a hair's breadth away from skinned apps: confusing, distracting, could cause problems for the visually impaired, may not work well with the user's screen settings (DPI, "large fonts", high-contrast mode, mono displays, etc.), and so forth. I shall sum up with my favourite quote:

"Whenever a programmer thinks 'Oooh, skins, what a cool idea!' his speakers should a cock-shaped soundwave and plunge it repeatedly into his skull."

[Lars]

Add one more supporter to hostile-yet-insightful Ed. I want to run apps that more or less respect my system's font/color/skinning preferences. I don't want developers foisting their bizarre style whims on me.

Being able to set per-application settings might be neat, though (for power users and weirdos).

[Brian]

I am inclined to agree with Ed and the others, but I am going to try to stay open-minded. You argue that better typography via custom fonts will improve applications. But, you don't give any evidence of this. Could you please cite an example of an application that improves users' experience by using non-standard typograph?

[Mike Hearn]

The GTK+ toolkit (dominant on Linux but runs on Windows too) allows you to do rich formatting and containment based layout (which you need for any serious work using formatted text) - your example of making words bold can be done by using a subset of html markup. More complex formatting can be done using the Pango text layout API.

[davidicus]

try this on for size: video games. the industry is growing at twice the rate of film, computer hardware, even the U.S. economy, yet i get to work with font strips. type all the characters you want to use (without going over memory budget) in a line about 16 pixels high, and export it. then software slices it into characters the game engine can butt up against one another. no kerning, no styles, you should see what T and A look like together. you can scale it, color it, and define a rectangle it can fill. true, i have a little more control. i can put almost-transparent pixels in by hand to add letterspace.

everything shouts to be heard above the music, sound effects, dozens of UI elements and the gratuitous onscreen action, so the word elegant is used when type is the textual equivalent of a Marshall stack on 9. (the elegant bits will be removed or reamplified before the game ships.)

i try to avoid 4pt Comic Sans but you might be surprised how many people in charge like "character."

4pt Comic huh? makes me wonder what kind of sites you frequent, Scott! :-P

[davidicus]

try this on for size: video games. the industry is growing at twice the rate of film, computer hardware, even the U.S. economy, yet i get to work with font strips. type all the characters you want to use (without going over memory budget) in a line about 16 pixels high, and export it. then software slices it into characters the game engine can butt up against one another. no kerning, no styles, you should see what T and A look like together. you can scale it, color it, and define a rectangle it can fill. true, i have a little more control. i can put almost-transparent pixels in by hand to add letterspace.

everything shouts to be heard above the music, sound effects, dozens of UI elements and the gratuitous onscreen action, so the word elegant is used when type is the textual equivalent of a Marshall stack on 9. (the elegant bits will be removed or reamplified before the game ships.)

i try to avoid 4pt Comic Sans but you might be surprised how many people in charge like "character."

4pt Comic huh? makes me wonder what kind of sites you frequent, Scott! :-P

[Sean Gerety]

Yes I agree with you about the blank stare. I tried to get a company to use Gill Sans for a data dense report, and the hoops that Adobe had you jumping through to get it and trying to explain why you would need another font for an application can drive you crazy. I'm digging WPF app's because you can imbed your fonts with the app.
Check out Fil Fortes blog for great font related info in WPF.

Sean