The SitePoint Podcast: Web Fonts with Jeff Veen

The SitePoint Podcast

Jeff Veen is one of the bright minds behind TypeKit, a new service that he sometimes describes as “an iTunes Store for web fonts”. In this interview, Kevin Yank gets Jeff’s thoughts on the cutting edge of web typography, and how web design is about to change forever.

Running time
0h50m
File size
23.00MB

Download Original File | View original post

Episode synopsis

Episode 23 of The SitePoint Podcast is now available! This week, Kevin Yank (@sentience) has a one-on-one chat with Jeff Veen (@veen), one of the bright minds behind Typekit.

Listen in your Browser

Play this episode directly in your browser! Just click the orange “play” button below:

A complete transcript of the interview is provided below.

Download this Episode

You can also download this episode as a standalone MP3 file. Here’s the link:

Subscribe to the Podcast

The SitePoint Podcast is on iTunes! Add the SitePoint Podcast to your iTunes player. Or, if you don’t use iTunes, you can subscribe to the feed directly.

Interview Transcript

Kevin: The SitePoint Podcast episode 23, for Friday, August 14th, 2009: “Web Fonts with Jeff Veen”.

Kevin: Hi, there and welcome back to the SitePoint Podcast—news, opinion, and fresh thinking for web developers and designers. I’m your host, Kevin Yank coming to you from SitePoint headquarters in Melbourne, Australia and I’m joined by my panel of co-hosts.

Brad: Brad Williams from WebDevStudios.

Patrick: Patrick O’Keefe of the iFroggy Network.

Stephan: And Stephan Segraves from Houston, Texas.

Kevin: It’s Friday, and that can mean only one thing: it’s time for the SitePoint Podcast. It’s just me again this week—or, rather, it’s just me and our special guest—because this show is an interview with Jeff Veen, one of the bright minds behind Typekit, a new service that Jeff sometimes describes as “an iTunes Store for web fonts”. But rather than me explaining it, let’s welcome the man himself: Jeff Veen, welcome to the SitePoint Podcast.

Jeff: Hey, thanks so much, Kevin. It’s good to be here.

Kevin: Good to hear from you. So, please, for our listeners, introduce yourself.

Jeff: Sure, I’m happy to. Hello everybody, my name is Jeff Veen and I am the CEO of Small Batch, Inc., a company that is currently building a product called Typekit, which I think we’ll have quite a bit to talk about today.

Before that, I spent a little bit of time at Google, where we did a bunch of design work around Google Analytics, which I’m sure many of your listeners are probably familiar with. We got to Google through an acquisition of a product called Measure Map which I built at a company called Adaptive Path, which is a consulting company that focus on web design and user experience here in San Francisco.

So that’s, in a nutshell, what I have been up to for the past few years and I’m looking forward to chatting about stuff.

Kevin: Alright. When someone meets you at a party, how is it you describe what you do? What’s the common thread?

Jeff: You know, it depends a lot on the party. Honestly, I tell people that I make stuff on the Web and that it is primary the ultimate design perspective. Well, I really don’t have any training in design; technically, I kind of fell into it. I got to the web with a journalism background early on when I was at Wired magazine, but my career has kind of moved more and more towards building things on the Web from a kind of a entrepreneurial point of view now but I’ve kind of worked for myself and built companies with a lot of fantastic friends and partners over the last few years and by that point, they’re asking me if they could get me another drink and they walk away.

Kevin: Maybe it’s from your background at Adaptive Path more than anything, but it seems like you approach things from a usability perspective, or at least that seems to be whenever a new project from Jeff Veen comes out, there always seems to be more attention than average spent on the usability of the thing. What is it about the web that keeps you coming back with new ideas? Is it because usability is different on the Web than elsewhere?

Jeff: One of things throughout my career that I’ve always been totally fascinated with is the blurring of the lines between people who make things and people who consume things on the Web. Like with television or even journalism, when I was working at newspapers, there was very much of this kind of small group of people, highly trained that they were responsible for making everything and that’s just totally went out the window when the Web came, right? And so I’ve always been super interested in things like social media, going all the way back to blogging where anybody can have a voice and anybody can publish and have an audience and share things, and I’ve always really been interested in that, and from that perspective, that gives us the requirement to have a lot of empathy in the design work we do, that we really focus on end users and to engage them and to make them part of the process because we’re also end users and they’re also developers, they’re also content providers. So that blurry line has always been really the driving force between all of the design work that we’ve done with all of the projects that I’ve been on.

Kevin: Great. So you mentioned your time at Google. As an ex-Googler— Alex Walker, our designer here at SitePoint was asking me if I thought you would have any perspective to share on Google Wave. Is that something you can talk about, is it something that you have a personal perspective on, were you involved in it at all?

Jeff: Actually, no. I wasn’t involved in that and to be honest, it was a rare example of Google being so secretive that when I saw the demo online so did everybody else, like it was all at the same time. I knew that there was a big project happening in the Sydney office and that it was, people were moving to Sydney to go work on it and nobody was talking about it. I think it’s fascinating like now, outside of Google and looking in, it is a great example of kind of how this bottom-up initiative that’s always worked at Google. There was always this mythology of the 20% time and talented engineers could go work on whatever they want and get support for it, and I think Google was an excellent example of that coming to fruition. There is a proven group of engineers that had a good idea and they got support for it internally and they ran with it, and they’ve done an amazing job.

Kevin: From a usability standpoint, what Alex is wondering at the moment is, is it practical, or even desirable, to weave together all of these much simpler systems of communication into one big solution? Is that something that has value bringing all of that together into something that may be more complex and difficult to use?

Jeff: Well, that’s a totally valid concern, right? And I think if I were to sort of put money on any Google solution, they would do that in a way that is open and embracing of a developer community, I think very similar to sort of the position that Twitter has taken where—to be perfectly honest, I use Twitter all day long every day, and I kind of hardly ever visit their website. There’s clients, there is my phone, right… and I totally expect Google Wave to be the first implementation of perhaps a new way of connecting and communicating with people, just like Twitter has been. And we don’t what the rules are going to be for that, and we don’t know if people are going to end up doing all of that stuff. Just like email was 20 years ago, it moved out of proprietary solutions and into something that you can consume however you wanted. So that would be my guess, my bet.

Kevin: Fingers crossed.

Jeff: Yeah, exactly.

Kevin: Well, quite a few years ago now, you wrote a book called The Art and Science of Web Design and a SitePoint forum user, Alex Dawson wants to know if you had to think about it, what are the most important changes that have come to web design since that book was published?

Jeff: That’s a great question. That was a long time ago too; I think it was 1999 when that book actually came out. So a tremendous amount had happened. If you think back to the year 2000, things like standard space web design was kind of a fringe thing, like big companies weren’t really embracing that and supporting that and it’s through the work of people like Zeldman and Eric Meyer and frankly, hundreds of designers out there really focused on standards-based design, as well as the sort of reemergence of the browser wars, right—has kind of converged on the fact that we kind of can take that for granted now. Like that’s not a big battle that we’ve got and fight, it’s a good design practice, and people do it all the time. Especially now that things like Firefox and Safari have really sort of taken a ton of market share away from the dominant players. I think that’s one of the biggest changes.

Actually, another really big change that happened in that time is the adoption curve of new browsers, and I think that’s something we don’t talk too much about these days. I know when I started my career in web design, when a new feature would land in a browser, we were all excited to use it but we knew it would be six, nine months, maybe over a year before we could really count on a big enough audience finally upgrading their browsers enough to being able to rely on those new features. Seeing things, for example with the @font-face font linking where a new browser comes out and within a matter of weeks, a huge proportion of the audience has upgraded Firefox or upgraded Safari. With Firefox, it simply asks you one time when you open the application, “Hey, do you mind if I do an update?” And it has already downloaded it and it swaps it out, you’ve got the new version, and that has fundamentally changed how quickly designers can embrace new technologies and frankly, how quickly the browser vendors could iterate and see what works.

Kevin: Some of that has to do with browser makers being smarter about how they introduce features, the thing of putting a proprietary prefix on CSS property names, not to get too technical but it means the way new features are being added to browsers freeze up developers to try these things out without necessarily breaking compatibility going forward or going backward.

Jeff: That’s exactly right and designers can then provide feedbacks and frankly, vote with their code, right? You can see what kind of stuff is working.

I’ve been watching really closely, in the WebKit nightlies, as we do these amazing CSS animations stuff, and it’s entirely built on top the core operating system technology so it’s highly performant, and it makes me super excited for what we’re going to be able to build probably some time in 2010—early 2010 if we get some consensus. I just think that’s an absolutely fascinating way of really showing a lot of innovation in the browser space, which to be honest, if you had asked me 10 ears ago, I would have said, “No, like I think that’s mostly sorted out now, you know and like, I think IE6 may be the last version we see…” remember all that stuff? I couldn’t be happier that these things are coming so quickly now.

Kevin: Well, you mentioned the reemergence of the browser wars and that’s true, but it really is a different kind of “war.” The first time around, there was a sense that someone had to win and we were all hedging our bets over who would win but now we’re quite happy if no one wins because the more competition is going on, the better the benefits for us.

Jeff: That’s exactly right. I totally agree. It’s more like we have the browser UN, right, where we have—actually the process is working now and we get how it goes and everybody’s getting along and…

Kevin: So you mentioned @font-face and that is really the big new feature that led to Typekit so for those who may not know, what is Typekit?

Jeff: Typekit is an application number building that sort of sits in between all of the different people that are interested in using typography on the Web. About 18 months ago, there was a post on A List Apart, Jeffrey Zeldman’s fantastic web developer website by Håkon Lie who is the Chief Technology Officer for Opera saying the next big thing is going to be web fonts and he had committed Opera to supporting it in the next version. Immediately after that, it started showing up in Safari and then Firefox announced that they would support it as well. It is a very simple way for designers to use, in their style sheets, a URL that points to a font on a server and their HTML then just renders using that font. So it is very similar to how we might, say, link to an image, or link to a bit of JavaScript. Now we can link to a font and when an HTML page renders in a browser, it will display in that font without having to use Flash or images or anything else. So really, the whole of typography can be opened up into browsers.

Now, this is something that’s been supported in Internet Explorer all the way back to, I think Internet Explorer 4, but certainly Internet Explorer 5, but it has been around for a while but Internet Explorer had done it in a very proprietary way using a font format that they had invented and they had patented and the only way to really use it in Internet Explorer was use a relatively bugging tool that was supposed to convert your font into their special format and link it up to the page and it really didn’t fit into how the designers work and so nobody really used it. Now these browsers were suggesting, “Well, why don’t we just use OpenType or TrueType fonts, which exists all over the world, like we have these forever, put them on your server, link them up and it just works and there’s been a tremendous amount of excitement about this. Designers are like, “This is fantastic! This is what we wanted for a long time, this is great.”

The sort of place where we have to slowdown and take stock of what’s happening, of course, is on the type designer and foundry side because they don’t have licenses that actually allow you to stick fonts on servers and distribute them all over the web. They are cautious and concerned about the fact that all of their intellectual property is just going to sort of become free and become widely distributed and be everywhere. So, they’re trying to find a solution that helps protect some their intellectual property.

We have seen through the last decade that clearly DRM solutions don’t work, right? Almost every solution that’s been tried, whether it was iTunes or some of Microsoft’s technologies or whatever, those companies have always backed off. The consumer is just not tolerating all the arcane rules and things like that. So that kind of stuff is not going to work.

So what Typekit is trying to do is to find a middle ground in between designers who are desperately been trying to get fonts onto their web pages and foundries cautiously trying to enter this new market and our solution is to host fonts on a centralized server, put a series of relevantly lightweight protections in place so that the only authorized sites, only people with a Typekit account can actually use those fonts and then we give you a link that you put into your pages that makes the font work and you can continue to work the way you always have. Whether you use an HTML editing tool or write the code by hand, the idea is to let designers just create their pages but the fonts are available to them.

So in a nutshell, that’s how it all works.

Kevin: So what attracted you to this project?

Jeff: Well, I had been thinking about what would come next when I was in Google. I left Google over a year ago now and started this new company called Small Batch with my long time friend and business partner, Bryan Mason. He and I had worked together at Adaptive Path. He ran the business of Adaptive Path, a consulting company, and he was looking for a new thing to do, and so he and I got together and started brainstorming a bunch of stuff that we could do. We did a conference, we did some work with Twitter, doing some consulting with them. We got together with a couple of other co-founders who had also been working with us at Google and had helped build Measure Map, Greg Veen and Ryan Carver. The four of us got together as we were doing this work at Twitter and said what could we do next? What would be our project? What would be something would really compelling to us?

And this is right about the holidays of last year, and just before that, there had been a few blog posts. I think Richard Rutter from Clearleft, and John Allsopp from Australia, from Sydney, Western Civ, and the Web Directions conferences, had started talking about, “Hey what about bringing fonts to the Web now that the browsers are supporting them, maybe there’s some new business models there?”

Kevin: Yeah, it was just heating up around then.

Jeff: Yeah, just heating up around then. I also—serendipitously—went to Australia and spent the Christmas holidays in Sydney and got together with John and had lunch with him, where we started talking and he started telling me about this, like there could be an idea here. There could we do something around trying to provide maybe fonts as a service, maybe like how iTunes is a service, maybe fonts could have sort of an iTunes for fonts. And it totally resonated. That’s an audience— The web developer audience, since my days at Webmonkey back in the 90s writing, that’s an audience that I’ve been connected with and felt part of and had met at conferences and I was like this is a perfect audience, the perfect set of technologies, it feels like a bit of a wild west land grab. Like, here this new technology comes out, nobody knows what to do and there’s a ton of excitement about it, it’s perfect.

So we came back and we talked to John some more, he’s an advisor for Typekit, so we talk to him sort of all the time about it. We sketched out the basic sort of architecture, how could it work, dug in to how the browser supported everything, went out and talked to investors and said we think this is going to be pretty big is, that it’s going to change the way that web designers design, the way web sites look, and we think that there’s a great opportunity here. We got some fantastic investors, including Evan Williams from Twitter, Caterina Fake from Flickr and Matt Mullenweg from WordPress and a whole bunch of other people. So we got people that were very native to the Web to say “Yes, we believe it and we support you.” And so that all came together … and then as luck would have it, Jason Santa Maria, one of the biggest font geeks in the world and phenomenal designer was just coming out of Happy Cog where he and Jeffrey Zeldman had worked for years to start looking for his own project until we started working with him as well. Everything came together and that’s how Typekit sort of got its start.

Kevin: So do you consider yourself a type geek?

Jeff: I have always been fascinated by typography but I’m not very good at it.

Kevin: I think that describes a lot of web designers.

Jeff: Yeah, I know, I think so and I think frankly, we’ve never really had to be. There is such a limited selection of fonts on the web, there has increasingly been more control over how we can craft what we had. I have always loved— I mean I do see typefaces when I look out in the world, like I see signs and I see books and everything, and I’m like “that’s gorgeous, I love that.” I’ve never had the opportunity to really dig in and work with them. So I think yeah, I think like a lot of web designers, I am so glad that we’re going to have that opportunity now so that I can finally actually refine that desire that I’ve had to work with type.

Kevin: Great. Well, here at SitePoint we’ve had the opportunity to play around with the Typekit preview a bit. The 36 fonts that are in the preview are a beautiful start, but can we expect hundreds, or even thousands, of fonts in the public launch? Like is Typekit aiming to be a boutique, a supermarket, or a warehouse for fonts?

Jeff: I haven’t really thought of those categories. Hundreds is the answer that you’re looking for, for launch, and then a variety of levels of service, if you can imagine. You’ll be able to choose how big of a library you want to be able to use. There will be some sort of very exclusive typefaces that are highly desirable that will be in the special libraries and things like that. But the desire here—the strong desire that I’ve had from the very beginning and we as a team have always sort of rallied around—is that designers should be able to remove a business decision from a creative decision. So you should be able to essentially look at this library of type and use whatever you want for whatever projects you’re working on, for whatever makes sense, and know that you essentially have a flat rate subscription to do that. You shouldn’t have to worry about what are the … like this is a gorgeous typeface, what are the particular usage scenarios that I’m allowed to use it for.

One of the big points of value that we’ve been trying to create is the simplification of all the licensing rules that are out there to say,if you use Typekit, here’s how it works and it’s very, very simple.

Kevin: Alright. So the business decision is do we want to invest in typographic control of our look online and once that decision is made, it’s creative freedom from there, that’s the idea.

Jeff: That’s right.

Kevin: Great. Does Typekit have exclusive distribution rights to the fonts that it will sell?

Jeff: No. I think there’s a tremendous opportunity for not just competition, but for raising the bar on design on the Web, and I see no need for exclusivity in any of that. There should be many different models for how typography on the Web should work. We are going to be presenting a number of them, including a sort of subscription-based model. I can’t wait to see how these all plays out.

Kevin: As you said, the biggest barrier that Typekit is taking down is the licensing issues surrounding bringing fonts to the Web. So obviously in the work you’ve done in setting up Typekit, you’ve spoken to probably as many type designers and foundries as possible. How receptive have they been to work you’re doing? Did you get a lot of “no”s?

Jeff: Well, as you can imagine, there’s a full spectrum. There were meetings where we sat down and type designers say, “this is exactly what we’ve been waiting for, where do we sign?” And they’ve been great partners, like digging deep into the technical specifications of OpenType to figure out what works on the browser, like unbelievable partners that we’ve had there.

There are also people that have been very skeptical, and I can totally understand that as well. The type industry has over the last 30 years has seen proposal after proposal for different formats and different technologies and different ways that people who know better are going to sell their fonts. And rightly so, they should be skeptical but for the most part, it’s been sort of in the middle. Like, “Well why don’t we try with a few of our typefaces and see how that might work and let’s see how we can grow that in the future…” and I think everybody’s really interested.

And I think across the board, we have had an acknowledgment from everybody that we’ve talked to that things are changing right now, that this isn’t just another like proposal for Microsoft or anything like that, but that the Web is ready for this, that there’s been a convergence of higher bandwidth and browser technology and designers ready and sort of a maturation of the whole industry that now is the time that we really address this and let’s figure that out. And you can see that, like if you go to look at Typophile, which is a popular online forum for type designers, or even with W3C Web Font mailing list, there’s an unbelievable amount of participation and interest in how these technologies play out and how they match up with what the needs of type designers and type foundries really are.

Kevin: Speaking of that, you recently wrote on the Typekit blog about your support for the dot web font file format proposal. What do you think that proposal, if it turns into a working technology, what does that achieve over what we have now?

Jeff: So, I think from a type designer point of view, they are simply asking that browsers support a format for fonts that is different for viewing than for creating. And that’s one of the reasons why this is such a big issue and why you can’t just say well, look, it’s worked for photographers and it’s worked for videos, it’s worked for music. Why would the browsers need to do anything special for fonts? The reality is that it is literally the source code of the tool that font designers make. They give you a font and they are giving you literally the entire source code and saying “here you go, you’ve got it now.” And so it does feel a little bit different.

That said, on the browser side of things, they need for an open web to work, to not be completely agnostic when it links to stuff. So there is this tension right there. I think as an industry, whether it’s a web industry or font industry or whatever, we need to sort of work through that and figure that out. Now, I don’t think we’ll ever put the genie back in the bottle; I think we will always like to OpenType fonts. I don’t think Mozilla’s going to stop doing that and Firefox and WebKit will take it away. But, I also think that there’s an opportunity for any kind of new format to help type designers sort of figure out the right thing that works best for them.

Now, for the reason that I think that Typekit should support that is because we completely support that process—an open exchange between the parties that are interested. That hasn’t traditionally happened in the past. When the web fonts first emerged back in 1998 or 1999 or whenever it was, it was literally like Microsoft made something up, Bitstream worked with Netscape, they made something up, they all watched, and it didn’t really feel like there was this open and collaborative discussion about it. So I’m super happy that that’s happening now.

I also think that, frankly, building a web-based font format is going to get around a lot of patenting and licensing issues that may be embedded deeply in some of the software that we have now. So as an analogy, when I started on the Web, we had GIF and we had JPEG and for a while, like there was this patent thing that said like, is every sight that has a gif on it going to have pay a licensing fee to the patent holders, I think it was Unasys at the time, right? And so there was concern about that, and so a group got together and did this completely open format called PNG files. And they’ve been really successful and it’s really worked. That doesn’t mean GIF and JPEG don’t work on the web anymore, but now there is an open and unencumbered file format for images that everybody has really embraced.

Kevin: The mere existence of that format removes the threat that existed with GIF.

Jeff: That’s right. So, I think that’s great. That may take a couple of years and that is not going to slow down web typography at all but it will give us an alternative that is completely open and that will be great. So yes, we totally support that and that’s the direction the industry should go.

I think at the same time, hosted font services like Typekit, have plenty of time to help develop a market, develop an industry, move into other things as well. I think there’s all kinds of opportunity for hosted styles and all of that is going to be happening in addition, in parallel with whatever standards-based movement we see.

Kevin: You mentioned earlier that something that the foundries are clearly worried about is the threat of piracy with their fonts. That if they take their fonts to the Web in the wrong way, that threat is going to remove the value of their product. Is that another case of trying to put the genie back in the bottle because it seems to me like the fonts are already out there, if what someone wants to do is steal fonts. Is that a real threat or is that just something you need to address to satisfy their fears?

Jeff: No. I wouldn’t necessarily characterize it as “the foundries are concerned with piracy.” The fact that there’s been browser development doesn’t change their position on that. You take any font you want and you put the word torrent behind it and you search for it in Google and it’s there. And all of the foundries know that, everybody knows that and there’s no putting that genie back into the bottle, I can guarantee that. That has not impacted the sales of the fonts whatsoever. It’s the reality of how the world works right now and they acknowledge that. What they are concerned about is the availability of fonts in such an open, and sort of cavalier manner, that people are confused about the need to pay for licenses or things like that.

The phrase that we’ve use over and over again is ‘casual misuse’, where I look at a web site, “Ooo, that’s a nice looking font.” I take the font and sell it and just start using it. I don’t realize that I’ve broken any sort of license or copyright. I think that’s something that we’ve seen… like if you look at the RIAA lawsuits here in America, it is mostly people that downloaded music and kind of didn’t realize that they were sharing it back; they didn’t realize that Limewire or Napster worked that way and suddenly, lawyers were sending them letters. That’s what the type industry doesn’t want to see happen and I have a lot of respect for that.

It is the exact same thing that Corbis or any of the other… Getty Images has with online stock photography. They want to make sure that… they totally realize that with an <img> tag, you can right click on it and pick the image. They just want to make sure people understand that these are licensed images and that there are certain mechanisms set up for compensating the people who those licenses.

So that’s what the type industry is looking at and suggesting, and that’s why we have, from the beginning, said that Typekit hasn’t tried to implement any DRM or anything like that but we are putting in place ways to protect our service, so that people don’t just hotlink to the fonts and aren’t just using the service that we’re providing without any payment, or that people are pulling fonts out of their cache file, installing them, and thinking that, that’s okay. So there are a few layers, from HTTP referrer checking through some segmented fonts and license text that you explicitly have to remove, that kind of stuff. Put all of those things in place and it’s something that resonates with the foundries that were working with and have talked to.

Kevin: Can we talk about Photoshop for a minute? Clearly Photoshop is a tool that a lot of web designers start a new design in. If they’re going to use a service-like Typekit to serve their fonts on their finished product, are they going to have also buy a print license to the font so that they can load it into the Photoshop and do their mockups?

Jeff: Right. Well, that’s a fantastic question because we’ve always said we want designers to be able to work the way that they always have, and so that’s something that we’re actively talking to foundries about, about to what extent can we still allow them to do that and it’s something that we have to figure out together with them and find a really good solution for. So right now, like I wanted to make sure that it was possible for designers who still code by hand or still to do the production of their sites, however they do it, whether use a blogging platform or whether they use content management system or whether they use Textmate and write markup all day. Photoshop is a piece of that and we’re actively looking at how we can help designers to do that.

Kevin: Yeah, so it’s fair to say it’s an unsolved problem at the moment, but it’s clearly one you’re working on.

Jeff: It is absolutely one thing we are focused on, yes.

Kevin: Speaking for myself, I think if I as a design firm had maybe committed to using Typekit for a year or something like that, I would think it fair then for the type to be available to me in other formats for re-use in my design work. I’m just thinking out loud here but that’s kind of what I would expect.

Jeff: No, that’s great feedback.

Kevin: One of the big technical problems that Typekit solves is this whole thing of Internet Explorer only supporting the EOT format for downloadable fonts and that mess creating that format can be. How has that format been to develop for?

Jeff: Well, it’s been challenging and I think that’s because honestly, it hasn’t been very widely implemented, right? If you think about lots of open source products, you’ve got millions of eyes and hundreds of hands actively developing and looking at these things and things get really hashed out and tools emerge right? There’s a couple of Python scripts that generate EOT, we’re using an open source library and modifying it deeply to get it to all work but that’s a lot of uncharted territory; I’ll be perfectly honest.

And so we have put a ton of effort into that and we have really great results, so that’s also one of the reasons why where you JavaScript so that you can – you put a link in your page, we generate the CSS and we serve the right CSS to the right browsers and the right font format to the browsers. So it is another one of our key points of value is that web designers won’t have to go through all that hassle to generate EOT if they want to support Internet Explorer. Now, I know that it’s become sort of like Internet Explorer as almost as an entire category has kind of it’s starting to take this like second level of priority for a lot of designers. Like, I do standards compliance design; it looks really good in Safari and Firefox and then I figure out what I can serve to Internet Explorer, but we also believe that typography is going to be a way that a lot of people really leverage their brands that they have a lot of equity in. You wouldn’t think of not sending your corporate logo to Internet Explorer and so likewise, I think if people sort of craft their brands around type treatments in web pages increasingly over the next month and years, that they’re not going to be able to just ignore Internet Explorer when it comes to that. So we’re going to have to do something there. And so that why we’re putting so much effort in investing so much and energy into figuring out how to best support the EOT format and to work with it every day.

Kevin: Yeah, just as an example, SitePoint recently spun off a new company called Flippa.com and in the design of the logo for that new company, we even had the discussion of “alright, for the text portion of this logo, we want to use a font that we will hopefully be able to serve to browsers as text, rather than as an image.” So it’s already creeping into the discussion.

What’s fascinating to me is that this ability— As critical as the licensing issues are, and solving those is a great strength of services like Typekit, one of the big points of value as you say that is going to get designers over the line is the fact that it solves the Internet Explorer problem, but if a format like .webfont comes along in a year or two, if everything goes perfectly, we see support for it in Internet Explorer 9 or something like that (dare I hope), that portion of your value proposition could fade away, and yet I think it’s what will get people in the door today and once they’re using a service like that, once they’re used to thinking of fonts as a service that they pay for, I think they’ll be comfortable doing that going forward, even if the Internet Explorer problem goes away.

Jeff: Oh, I totally agree. I’ll give you an analogy. I’ve got a friend from way back, named Lynda Weinman that I’m sure many long-time developers are familiar with, and she has built Lynda.com into this kind of publishing empire—publishing and training and all this great stuff—she started her career grappling with the Netscape color cube. Like that’s how he got started. Like color is a disaster in the web, you only have 256 and there are these colors and you have to render your images… She wrote book after book about dealing with web color, was tremendously successful, and of course… I mean we haven’t thought about that in a decade now, right? But clearly, there are points of pain that designers face every day today, and I think Typekit can solve many of those points of pain and will continue to do that even if some them of go away in the future.

Kevin: Speaking of points of pain, what are your thoughts on some of the cross-browser, cross-platform rendering issues that exist with downloadable fonts?

Jeff: There’s kind of three places where that can be an issue. One is in the browser and operating system. One is in the font files themselves, and then one is in some of the services that we can provide through JavaScript’s libraries and through different style sheets for different browsers. So we are, of course, doing as much as we possibly can, right? There are like Firefox and Safari, they interpret some of the internal metrics of OpenType files slightly differently and you can correct for that with CSS. So we’re doing some of that kind of stuff, so that at least you get comparable metrics in the two browsers.

There are ways of working with type designers so that the foundries that are part of Typekit, we are normalizing a lot of the internal metrics of their fonts or helping them to figure out what works best on the Web, that sort of give and take in that collaboration. So, that’s been fantastic.

Fonts show up and some of the very early test cases that people have published with the technology preview of Typekit, people have noticed sometimes the font gets clipped in the baseline and things like that, that’s entirely stuff that we’re correcting with the foundries. And we’re working because, you know, they’ve never had to put their fonts in browsers and we’re sorting all of that kind of stuff out.

And then there’s all the rendering engines themselves, and that is going to get even more complicated, I can assure you. Like, I’ve seen there’s an open bug in Bugzilla for the next version of Firefox that says well maybe we should use a different rendering engine for fonts just that were linked rather than fonts that are native to the browser. Yeah, it’s going to get really complicated. My best case scenari—what I would love to see—is that there is a tradeoff between what designers can control over how it’s rendered that then kind of cascades to what users really want. And you saw, probably, we’re tracking what happened when Safari for Windows launched and they used a different font rendering system. Right? The people hated it or they loved it. It was one or the other, but nobody was neutral on that, and so quickly, Safari put a preference and so you could put it back to ClearType.

So, I think it would be great if the designers had control over how their web pages were rendered by the browsers but then end users could decide whether or not they wanted to let designers have that control. I mean, kind of the way that style sheets work anyway, right? So that’s going to be complicated because it takes us a while to figure that out.

I think another good example of this is what happens while we’re waiting for the font to get to that browser. Like, all the browsers do that differently as well.

Kevin: Yeah. I know when I did some testing in Safari and I hit a page with some custom fonts, it’s like I could hear some gears squeaking inside the browser as a bit of logic that is buried so deeply because, as far as the browser’s concerned, “wow, I’ve never had to do that before” and it just sort of ground to life. You know, I saw the spinning beach ball for a few seconds and then uuugghhh, it got it and the font was there. But, yeah, it seems like the browsers, they support this but supporting it and supporting it well are two different things.

Jeff: Yeah, well, that’s going to be iterative.

Kevin: Yeah, exactly. So, once the designers start using this, the browsers are going to have some work to do to improve their support for it.

Jeff: Yeah and again, I’m thankful that that iteration happens much more quickly now.

There is also some control you can have over that and we’ve been experimenting with that quite a bit. Our JavaScript solution is based on jQuery, it has the ability to hold off on rendering the fonts until documentReady, for example. I don’t know if that’s the right solution but we can certainly offer that as an option. So, again, try to put some of that control back into the designer’s hands and try to, maybe, smooth out the differences between the different browsers. I don’t know. We’re experimenting with that. We’ll see what works.

I think there’s also going to be the responsibility of the designers. You could put a couple of megabytes worth of photos on a page, and your users are probably going to complain and they’re going to complain by hitting the Back button. We’ve seen that.

Performance is one of the most important parts of usability. It always has been. That hasn’t changed. When I was at Google and when the rest of the Typekit team, when we were at Google, we focused on latency as a company priority. There were times when the whole company would say, “For the next three weeks, no features get added to any of our products. All we’re going to work on is trimming milliseconds from every user experience.” And so, I think there are features that we’re putting into Typekit that are going to help with that. So, you don’t need to send an entire font if you don’t need the entire font.

Kevin: Yeah, you might just need the five letters in your logo.

Jeff: That’s right. So we are subsetting fonts aggressively so that designers can decide exactly what they want. Like if you’re just using that font for the logo, just send those characters. But if you need all those foreign currency symbols, by all means, add them back in. If you’ve been experimenting a little bit with the Typekit interface, you can see that we’ve got all of these controls for what weights you want to put in, what set of glyphs you want to put in, that kind of stuff; trying to make it very clear that every decision you make is going to cost you a bit of bandwidth. I’ve seen some really, really beautiful stuff that’s done with 20 or 30K worth of fonts.

We’ve also put a lot of effort into making sure that the fonts are geographically located. So, if you are viewing the SitePoint page from you office there in Melbourne, you’re loading the font from our data center in Sydney. Whereas I load it from San Jose, we’ve got fonts all over the world—in Europe, in Asia, across North America—so the latency is very, very fast. We’ve gotten latency under 75 milliseconds for the request.

I’ve seen some concern about, “Well, it’s a third party service and I don’t trust third party services…” Once you start experimenting with how a global network of data centers work, you’ll see that the fact that it can be as fast as any web site that’s out there.

So, a combination of all of this in the mix is going to help us get through some of these early steps in web typography.

Kevin: Okay. Well, we may have covered some of this already but, by offering properly licensed downloadable fonts that browsers supports today, Typekit removes a huge barrier for sophisticated type design on the Web. What is the next problem? Once designers have Typekit and they start using it, what’s the next barrier to sophisticated typography that they’re going to encounter and who’s problem is that?

Jeff: I think we have to learn how to do typography on the Web. I don’t think we know how, honestly, as a community, and I think focusing on supporting that community is going to be really important.

I look back, with inspiration, on what designers like Jeffrey Zeldman and Doug Bowman did with standards-based design a few years ago, where we kind of didn’t know how to do it and they led the way. Doug would do these amazing designs and people would view source and he’d write up tutorials and they’d go, “Holy Cow! I can totally do that! Like, wow! That’s amazing.” I think we have to do that with typography now.

I think we clearly need like what Dave Shea did with the CSS Zen Garden, we need a fonts garden, right? And so, we have been looking very closely at how we can support all of that. How we can take best practices and examples and inspirations of things that have been built, not just with Typekit, but clearly with all the Typekit fonts, and expose that to the world and teach people like what is possible to do now that we don’t have to rely on Flash or images to have some typographic quality in our pages now.

Kevin: How will Typekit, and services like it, change typography or change type design itself? Because there are fonts that, no matter how good the rendering technology gets, they’re just not going to look good on screen. And I think there are fonts that haven’t been designed yet that will look great on the Web.

Jeff: And I think there’s also, to add to your point, constraints that type designers have never had to consider before, like file size. Right? We’re going to need to not only optimize on screen hinting for 9 point type and make it really legible and get the kerning pairs and the hinting and get all that stuff to really look good at screen resolutions, but we’re also going to have to be concerned with network performance, and the way the browsers handle things, and all of the stuff that we’re going to start to see in CSS. Like, what happens with ligatures when your filling out form fields. Has anybody thought about that? You know what I mean? And the fact is that, yes, people have thought about that. They’ve worked on Firefox and they’ve worked on WebKit and they’re putting that stuff in there but, man, we’ve got a lot of ground to cover both as web designers and as type designers.

Kevin: As designers sink their teeth into the new possibilities that fonts bring, they’re going to be finding, I guess, fonts that work, fonts that don’t, fonts that work in unexpected ways; will Typekit be exploring along with them and providing some guidance to designers?

Jeff: We always have. We already have been. We absolutely have been, both web and type designers, we have been really digging in and seeing what’s working and we are going to be building and launching lots of, sort of, community oriented features. It’s sort of Web Typography 101. Like, here’s how it works, here’s where you go and do that kind of stuff because, ultimately, like our goal here is to make the whole Web better. I am a 100% convinced that web typography is going to do that. We’re going to have some more semantic text on the Web, it’s going to have richer design applied to it. The Web is going to get more accessible. We’re going to have better search engine optimization. Like all of this stuff is going to get better because we can finally use HTML with fonts.

So, I think we have a lot to learn, and I think Typekit is going to try to be at the center of a lot of that, trying to help promote best practices and make the Web a better place.

Kevin: Speaking for SitePoint, we look forward to showcasing a lot of that work.

Jeff, thanks for joining us. Would you like to tell our listeners where they can go to follow you and to follow up on stuff they’ve learned about in this podcast?

Jeff: Sure, absolutely. You can go to typekit.com and you can do three things there. You can enter your email address, so that you can be one of the first to get an invitation when we start rolling those out very soon. You can also follow a link over to our blog, where we’re really getting deep into the technology of how all of this works, and then you can also follow us on Twitter, where we have a pretty engaged conversation with everybody.

That’s all at typekit.com.

Kevin: Great. Thanks again for joining us.

Jeff: Thanks so much, Kevin. This was a fantastic conversation. I really appreciate it.

Kevin: And thanks for listening to the SitePoint Podcast. If you have any thoughts or questions about today’s interview, please do get in touch. You can find SitePoint on Twitter @sitepointdotcom, and you can find me on Twitter @sentience. Visit sitepoint.com/podcast to leave a comment on this show and to subscribe to get every show automatically.

We’ll be back next week with another news and commentary show with our usual panel of experts.

The SitePoint Podcast is produced by Carl Longnecker, and I’m Kevin Yank. Bye for now.

Thanks for listening! Feel free to let us know how we’re doing, or to continue the discussion, using the comments field below.

You might also like...

Comments

Contribute

Why not write for us? Or you could submit an event or a user group in your area. Alternatively just tell us what you think!

Our tools

We've got automatic conversion tools to convert C# to VB.NET, VB.NET to C#. Also you can compress javascript and compress css and generate sql connection strings.

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” - Martin Fowler