Towards the end of last year, ustwo™ released the hundred selling, million downloaded app for iPhone, HappySnapper.
HappySnapper was pitched as our “Anti-social Social Photosharing app”—a good half year before Color managed to make anti-social photosharing a $41 million joke without a punchline.
HappySnapper encouraged users to take shots of their friends and “punk” them with goofy prop stickers and share them via Email, Twitter and Facebook.
Fast forward a few months, a piracy explosion and a Free App A Day spike later and it turns out HappySnapper is about as big in Asia as Cheap Trick—the band, not the sales tactic. That’s pretty big, for readers who are either too young to know of Cheap Trick, or have too much self-respect to.
This popularity, coupled with our strategy of expanding our own IP onto other platforms has led to us prepping an Android version of HappySnapper.
At ustwo™ we emphasise delivering experiences tailored to the platforms that they’re to be experienced on. As such, HappySnapper Android has been redesigned by our UX team from the ground up to take into account the differences between the iOS and Android human interface guidelines.
In regards to design, adapting for the HIG has been the easiest of tasks in porting an app over to Android. The way HappySnapper works on Android is different to iOS, but it needs to be. Android has hard keys where iOS doesn’t, and users expect certain interactions that they wouldn’t on iOS.
This is a matter of preference and accustomisation—a topic well covered by Jacob Creech on behalf of Spyre Studios here (http://spyrestudios.com/android-vs-ios-a-usability-battle/)—and doesn’t effect whether something is better or worse but rather what is expected.
One problem that we are facing with designing for Android though, is the barebones approach to typography that the Open Handset Alliance has taken with Android.
HappySnapper’s USP was for users to be able to edit text on stickers to insult their friends in ways that only their wit could. Because of the variety of stickers available, HappySnapper relies on a selection of typefaces for its charm.
At last count, every iOS device on the planet has at least 40 typefaces ready to use— granted, a proportion of these are non-Latin scripts, but we’ll get to this later. The only guaranteed typefaces available for use on any given Android device on this planet: three. And these are all variations of Droid.
At this point I want to commend the Open Handset Alliance on commissioning Steve Matteson at Ascender to design Droid specifically for usage on mobile devices. It demonstrates that at least some thought and care has been given to typography on Android and us type nerds get affectionate to any company that commissions a custom typeface.
However, as elegant, robust and full-featured as Droid’s current family is (sans, serifed, monospaced), it is not a one-size fits all for an app that bases its appeal around personality and charm.
All of the stickers on the iOS version of HappySnapper use bundled typefaces. The diagram below illustrates the range and variety of stickers included in HappySnapper and the built-in iOS typefaces used for them, and how the stickers would appear were they to be done with the pre-installed typefaces on Droid.
[graphic of HappySnapper stickers rendered in Droid]
The existing workaround to this problem is to embed the font data into the binary. Workaround—because it’s no solution. Any professional designer will be able to tell you the problems with this.
A typeface—at least a good typeface— takes weeks, months, years to design. Once basic sketches have been done, the letterforms need to be digitised and tested. If you want to know what testing a typeface is like, I can only illustrate it with how my third year type design lecturer described it—“it’s like fucking ants”.
After the shapes for the letters have been digitised—keeping in mind that a character set doesn’t just end in A-Z, the Latin unicode range is over 800 characters—the type designer (or at least their intern) needs to test combinations of glyphs, not just in English, but in languages where combinations such as “gj”, “sz”, “fh”, “fb” are if not common, at least exist.
After this has been done with one weight, it needs to be done with the others. If your typeface has as many weights as something like Seb Lester’s Soho, then you can see how the £500+ price tag for whole family is not an outlandish pricetag for something with so much love and craft invested in it.
I am exaggerating the plight of the type designer slightly for effect here—there are tools which can assist in the of fucking ants more efficiently but that’s not to take away from the fact that type design is a skill and an art not unlike those which people do regularly pay good money for, which brings us back to the embedding font data workaround.
If you purchase a typeface, you buy a licence to use that on the number of machines your licence is for. With most foundries, this is five machines, but it varies. Most foundries that I have purchased typefaces from explicity state that the font code is not to be embedded into any application. This is understandable. An analogy would be the usage of music made by a musician in your app.
Just because Leper Messiah by Metallica is the perfect soundtrack for your app, it doesn’t mean you can use it without giving James Hetfield and co. his dues. Much in the same way that Officina would be perfect for your app, it doesn’t mean you can embed it without giving Spiekerman his.
At this stage I want to point out if you don’t see why you can’t see why you can’t just use Leper Messiah or Officina without paying for usage rights, then I don’t think this post is for you.
Usage rights vary. Some forward-looking foundries apply similar rules to the embedding of their font data as if they were embedded in a PDF file, however there are still some that insist on bespoke licenses for the usage of their IP. These licenses can be decided on a fee paid for x units sold, which is not cheap, or a blanket licence, which is definitely not cheap. As a large percentage of developers on iOS and Android are independents, the last thing you want to be blowing your moonlighting budget on is the licensing of a typeface. However, if it is the first thing you want to blow your budget on, I commend you and suggest you stop reading and go back to making your app—your heart is in the right place.
If you wanted a piece of music that _sounded_ like Leper Messiah but didn’t want to, or more likely, couldn’t afford to pay the fee to use it, you can get something that _sounds like_ Leper Messiah, flatten a few notes here and there, strip out the vocal and you’d probably be fairly clear of litigation, although in Metallica’s case, probably not.
To take this back to the world of typography, there are things you can do to have something that _looks like_ a typeface you want to use.
The first thing you can do is do what Microsoft did with Windows 3.1. Instead of paying what would have been a massive fee for licensing Helvetica, they made something that looked like Helvetica, hacked off the nice bits and called it Arial. This is generally too time intensive for most app developers.
Secondly, you can find a knock-off on a free font website which seems to be the way that most developers approach this. The problem with this method is most of the typefaces found on free font websites have been made by amateurs, lack full character sets (let’s not bring up multilingual support) and haven’t been rigorously tested in the same way that a professionally produced set has been. When you pay for a typeface, you’re paying for the comfort that it will work exactly as you expect it.
That’s not to take away from free fonts—there are scores of free fonts out there which are of outstanding quality—the most high profile in recent memory is Jos Buivenga’s Museo. Another favourite is Cristobal Henestrosa’s Espinosa http://new.myfonts.com/fonts/estudio-ch/espinosa-nova/regular/. Mention must be made here of Ray Larabie, the free font king, whose faces have been seen on covers of video games and as casino signage. However in both these cases, the designers have only opted to make a few weights of the face available for free, and even then the free licence doesn’t extend to embedding font code into the app binary.
A third, more drastic and more vintage way is to create an asset sheet for the typeface—a practice common in video game development. This is a sneaky way that allows you to use the typeface, but increases your development overhead and ruins the work that the typographer put into making their “T”s and “a”s sit comfortably next to each other.
None of these situations are ideal.
To contrast, iOS for iPhone* ships with 40 families, by my reading 18 of which are Latin scripts. A large proportion of these are Microsoft compatibility faces (Arial, Trebuchet, Times NR, etc.) but in there are classics such as Baskerville, Futura, Palatino and the favourite of design students graduating in the 90s—Helvetica Neue.
*iPad version ships with more faces, including Bodonis, Gill, Hoefler Text and Optima
There’s a school of thought amongst designers and typographers that a solid type collection should only consist of six to a dozen faces. There is a large degree of truth to that. There is also a large degree of ignorance about it also—John Boardley writes up his thoughts about it here http://ilovetypography.com/2010/04/17/the-vignelli-12-or-we-use-too-many-fonts/ but if in any case we are restricted to a limited number of faces, let’s hope those faces are as classic, robust and well-designed as possible.
iOS’ mixture of type design classics as well as a few goofy ones that aren’t quite classics but can be used by designers wanting to add a bit of Lemonade-stand charm to their apps is a boon for app developers like ourselves who want to create reliable, high quality products with personality with as little overhead as possible.
By including these typefaces with the operating system at a fundamental level, Apple has shouldered the cost of the licence for the ease of convenience of designers wanting to customise their interfaces. HappySnapper on iOS has benefited as a result.
To be fair, Android isn’t the only platform that suffers from the problem of a limited typeface selection, I wasn’t around in the days of Symbian to know better but have heard stories of sprite sheets being collated for typefaces to be used in games and Windows 3.1 essentially had only enough typefaces to service what Droid is doing very well for Android (Arial for sans, Times New Roman for serif, Courier for monospace and symbol faces), however in a world which is growing in typographic knowledge—knowingly or not, and a world which knows that there is a better solution, one has to wonder why the Open Handset Alliance took this route.
As mentioned above, someone there obviously has an interest in typography and understands its importance otherwise Droid would never have been commissioned.
One of the main selling points of Android is its relative openness—almost any vendor can manufacture Android hardware and as Android is free to licence to use on a device, having a royalty-paid model for each typeface licensed isn’t something that can be uniformly enforced, unless the Open Handset Alliance or Google was to buy an outright licence for the usage of a range of typefaces for the platform, which would be exorbitant. Google has deep pockets, but it wouldn’t surprise me if the licensing of a bunch of typefaces for use on all Android devices beyond Droid be seen as an unnecessary cost.
Take, by contrast, Apple’s approach to typography. Apple have commissioned typefaces since System 7’s Chicago designed by Susan Kare, and willingly paid for licenses for the real deal (Helvetica) rather than save a pennies for a universally derided knock-off (Arial) and making the typographic world poorer because of it.
However, Apple’s business model differs to Google’s completely. Apple manufacture the hardware and design the software for their devices. Every device they sell, they have had complete control over, including the bottom line. The licence fee for the typefaces that they’ve paid for are taken out of their bottom line, but also directly enhance the experience for the users.
In contrast, were the Open Handset Alliance to license a similar amount of faces for Android, that cost would have to be worn by someone, and one would think Android would look a less appealing proposition if there was a price tag attached to it. In addition to this, I imagine agreeing which typefaces to include across a board of 80 companies wouldn’t be the most pleasant experience.
More likely the approach to “openness” extends to typography—vendors and developers can pick and choose which faces to include in their distribution / apps and sort out their own licenses. This is commendable—not every distro is going to need a script face—however, in this case, by not including at least a selection of faces hinders the uniqueness and charm that independent developers can add to their applications without incurring additional fees or reading through labyrinthine license documentation.
1 note, July 7, 2011