How Cloud Computing Made Web Typography Better For Everyone

Co.Design talks to Mandy Brown of Typekit about why the service, which was recently acquired by Adobe, improved the web (and not just for designers).

How Cloud Computing Made Web Typography Better For Everyone

What’s makes sites like A Working Library and Pictory stand out from the pack in terms of readability? Clear, humane typography, of course. But what makes that possible? Web fonts: legally-licensed real typefaces dynamically served via “the cloud” using Javascript and CSS. Sound like Greek to you? Me too. Which is why, after I heard that web font pioneer Typekit was recently acquired by Adobe, I wanted to know what the BFD was. So I got in touch with Typekit’s Communications Director Mandy Brown (who also created A Working Library and contributes to web-design bible A List Apart), and asked her to explain it to me.


Before Typekit, what options did a web designer have for incorporating imaginative typography into her site designs?

Before web fonts, type designers offered desktop font licenses that web designers could use to replace fonts on the web: either as static images, or (if permitted by the license) via Flash or JavaScript techniques like sIFR and Cufon. None of these options were ideal, however; they were hard to maintain (a change in copy could mean cutting a new image), and they presented issues with both accessibility and search-engine optimization. In addition, they were very fragile: resizing your browser, or loading a site on a mobile device, could easily break otherwise well-crafted desktop layouts. They offered none of the flexibility we needed as web designers.

[Samples on Typekit’s website for Museo Slab, our own headline typeface]

That said, a lot of really interesting work went into those techniques, and they were formative experiments in web type. Many designers worked very hard to push these methods as far as they could, and we learned a lot about web type during that time. I also think the clear demand for better web typography helped define the need for products like Typekit, as well as WOFF (the web open font format).

What about type designers: before Typekit, how did they get paid when web designers would use their work? Was there a lot of typeface piracy — was it simply expected?

Type designers were paid for a desktop license (which all type foundries of course continue to sell). Desktop licenses are typically priced according to seats (or users): an organization with many designers using a font would pay a higher price than a single, independent designer. Typekit (and other subscription services) open up a new model: pay per use (i.e., pageview), rather than per user. This is something many foundries have long been interested in, but the technology of a desktop font made it difficult to negotiate. A subscription model makes web fonts accessible to all (by keeping prices reasonable for designers working on very low-traffic sites), while also providing a recurring revenue stream for the foundries.

What technology had to become standard on the web in order for something like Typekit to even exist? How are these technologies changing in a way that helps web typography get better?


The two key needs were reliable cloud serving and advancements in the browser landscape. Cloud serving has been around forever, but only in the last few years has it matured sufficiently for most people to trust it for critical elements of their site.

On the browser side, Typekit is made possible by pervasive, robust support for @font-face and JavaScript. @font-face is feature of the CSS spec for embedding fonts on the web; the spec has been around for a while, but it didn’t take off until Apple added support to Safari, which led Firefox and Chrome to support it, too. (In a reversal of the typical web standards process, Internet Explorer has supported @font-face since version 4, but only with their own, proprietary font format.) Wide adoption of @font-face led to conversations that resulted in the creation of WOFF (now the standard format for web fonts) and advanced typographic properties in CSS3.

Similarly, the rise of JavaScript and Ajax applications forced browser makers to improve their support for JavaScript, which is necessary to serve fonts to all browsers at scale.

How does “better typography” make the web better for everyone? Doesn’t it just make it prettier to look at for design enthusiasts?

In a word: no. Better typography improves reading and understanding, and makes the experience of the web better for all users, not only those who obsess over the details. Good typography can mean the difference between a reader getting all the way to the end of an article — and looking for more — versus giving up with fatigue after the first paragraph. When paired with smart copywriting and a good strategy, it can invoke a sense of trust in an application or service; it can help persuade someone to buy, or foster an emotional connection that keeps users returning.

Poorly considered typography, on the other hand, can alienate or offend, or signal the wrong qualities: think of a news site that uses a font that is too casual, and therefore evokes immaturity instead of authority; or a hip clothing retailer marred by a generic font that doesn’t communicate their uniqueness. Nearly everything we click or interact with on the web is type, making typography crucial to those experiences.

Additionally, using real fonts (and not font replacement techniques like sIFR) means that all the type on a site is searchable, indexable, translatable, and accessible. It allows web designers to craft exceptional experiences on the web, while also taking advantage of what the web does best: making content available (and discoverable) to all.


Now that Adobe has acquired Typekit, what changes or innovations are in store for the service? Will being part of Adobe force changes that Typekit users may not like at first?

The foremost advantage will be our ability to integrate web fonts into a designer’s workflow. Typekit has thus far been mostly about the production of a website, offering fonts in the browser and no where else. But designers work with fonts before they get to the browser, too: from early sketches to comps to client presentations, and then on to implementation. Adobe’s products are deeply integrated to that designer workflow, and we’re eager and excited about the possibilities of making type available throughout that entire process.

On the other side, Adobe benefits from a successful subscription service and our strong commitment to our community, both of which will serve us well as we integrate Typekit into Adobe’s forthcoming Creative Cloud service. A lot remains to be decided about how our two companies will work together, but there are several principles by which we will make those decisions: a deep concern and respect for the people who use Typekit, a love of good typography, and a healthy obsession with working fast and shipping often. Whatever else happens, these beliefs will remain a constant.

[Top image by Kevin Dooley]

About the author

John Pavlus is a writer and filmmaker focusing on science, tech, and design topics. His writing has appeared in Wired, New York, Scientific American, Technology Review, BBC Future, and other outlets.