Have you ever wondered why most websites use the same handful of fonts? There are only a limited number of fonts that every computer ships with. These are known as “web-safe fonts“, and most developers stay within that selection to ensure a consistent experience for all site visitors.
So how do you get beyond Verdana and Times New Roman? There are three options:
The most straight-forward solution is to create an image of the text you want. This way you can have complete control over the size and spacing. This is both a good and a bad thing: some people need to increase the font size on their browser to be able to read the copy. When you use an image, you may be limiting the ease of use of your site.
Using images in place of text also means you need to put a new file up on your web server every time something changes. This can be time-consuming if you have a lot of copy to change, and there may be a slight lag on the user’s end while they are waiting for images to be displayed from the server.
Lastly, putting content into an image makes it illegible for machines. You will need to ensure your developer is adding “alt text” (“alternative”) to any images with text in them. This helps users of screen readers as well as search engine spiders to understand the content of your page. It may not be pretty, but it will ensure the content is available for those who aren’t looking at your interface.
Building a site (or even just a portion of a site) in Flash means you are not limited by what fonts the user has on his system. Flash runs in its own player and all the necessary files (fonts, images, etc) are included within the movie itself. Note there may still be slight differences between a Flash movie made on a Mac and one made on a PC.
The biggest challenge to building in Flash is having a Flash developer create it. A Flash movie can be created with all the assets incorporated directly into the .swf itself, in which case the file itself must be changed and “republished” any time there is a change. Alternatively, a .swf can read from an external data source, so changes made in a database, an XML file or elsewhere can simply drive what’s being displayed in Flash.
Google is steadily getting better at indexing Flash, so there are fewer concerns that your content is being blocked from search engines or users of assistive technology. However, Flash doesn’t run on the iPhone, so you do risk preventing some visitors from accessing your content.
Another technique is sIFR (Scalable Inman Flash Replacement). sIFR replaces text written to the page with a small Flash piece. This overcomes some of the limitations listed above: content is written to the page so it is indexable, and there is no need for a developer to create new Flash pieces when things change.
Making sIFR look good takes some work: generally the text is seen on the page for a moment before it is replaced, so effort must be made to ensure it is not too distracting a ‘swap’.
sIFR was used to get the custom font in the tagline. The first image shows what the site looks like before the Flash loads (or if you had Flash disabled), the second is the desired effect.
The best option?
There is no single best option for using custom fonts, and it’s perfectly okay to mix and match the options. On the People’s Choice Awards site (from which all the examples I’ve displayed were taken), we used all three:
We used images for the navigation. These were unlikely to change frequently. For headers, we used sIFR, and for more interactive pieces we created Flash modules. These read from an external data source so that we could update the content via an admin interface and simply have it displayed within the Flash piece.
So while there are a suite of standard web fonts to use for body copy, there are certainly options for including custom fonts as well. It’s simply a matter of balancing the ease of update and use with the esthetic benefits. Knowing these options and the implications can help with such decisions.