Tuesday August 5, 2014

• The Colour and the Shape: Custom Fonts in System UI

The device-becomes-the-app nature of iOS is an interesting visual design playground. As a designer, you control every color and shape on the screen with no need to worry about how it will look next to any other app. When the user is in your app, you own the screen.

…Except for the status bar — that’s Helvetica Neue. And share sheets. And Alerts. And in action sheets. Oh, and in the swipe-the-cell UI in iOS 8. In fact any stock UI with text baked in is pretty much going to use Helvetica Neue in red, black, and blue. Hope you like it.

Maybe this is about consistency of experience. Perhaps Apple thinks that people with bad taste will use an unreadable custom font in a UIAlert and confuse users. Well yeah, of course they will. But don’t throw the baby out with the bathwater. Tasteless developers are already making terrible-looking apps. What we’re doing now is forcing good developers to make watered-down apps.

Open up Overcast and marvel at the beautiful Concourse. The entire UI is built around it, and the results are beautifully utilitarian. Concourse and orange are almost the entirety of Overcast’s branding, and because color and typography are used so effectively, the voice comes through clearly. Until you tap on the share button and and get slapped in the face with a wall of Helvetica Neue. “Cancel” indeed.

Similarly, Ideal Sans is the heart of Vesper. Hoefler & Co have made one of my favorite typefaces ever. It’s a thrill to design for it and to watch the text come to life. Then I go to delete a note and I’m heartbroken to watch Helvetica Neue slide up my screen in candy-shell shades of red and blue. As the designer, it steals control from me. As a user, it interrupts my experience. And worse, for no reason.

Brent Simmons touches on this:

Though we need to work efficiently, design still matters, and Vesper is designed around typography. We’re not even going to think for one second about dropping the embedded font.

But that leads to this dilemma: do we switch to the standard controls that don’t let us use our font, or do we stick with our custom controls?

Our choices are to either give in to Apple’s design or spend time and resources re-implementing the wheel just to keep our design consistent. This is a horrible position to be in, and still doesn’t account for share sheets, which aren’t even possible to roll ourselves.

Sometimes the difference is less stark. Glassboard uses Atlas Grotesk, which is visually similar enough to Helvetica that most people won’t spot the differences right away. Glassboard also features vibrant colors, so Apple’s stock buttons don’t stand out as much. But this is the exception that proves the rule; app designers should be allowed to stray from Apple’s visual design choices without a systemic punishment built into the APIs. Glassboard gets a pass for not straying too far.

On OS X, it’s fair to say that the system font is the better choice for UI. Preference windows in Ideal Sans would look silly and out of place. Not just for consistency between windows, but for the sake of tradition. You can do whatever you like with the content but a Mac app is a Mac app. It needs to feel like and coexist with other Mac apps.

When Apple gave us the ability to embed custom fonts into apps with iOS, the implicit promise was that we’d be able to create immersive or at least immersively opinionated interfaces. To force Helvetica Neue into the equation with predetermined colors doesn’t mean experiential consistency, it means that designers are forced to either accept that parts of their interface are going to look weird, or back down and design around Apple’s choices. Neither is a winning formula.

That this is even a problem post-Retina is doubly perplexing. Retina screens have once again placed typography at the forefront of design, allowing us to breathe life into words themselves as imagery. It’s a damn shame we’re not given more room to do so.

Apple should give developers the ability to use embedded custom fonts in alerts, share sheets, action sheets, under-the-cell buttons, and so on. There’s no technical reason not to, and every philosophical reason why they should. If the concern is consistency, the right thing to do is set expectations and guidelines in the HIG, and enforce them in app review.