A Not-So-Sweet Tale of Digital Type

Recently, I entered a website that I designed in a juried show. A website I’m really proud of and would consider to be some of my best work, if not the best of my work. Sticky with its visitors, easy to use, loaded with valuable information, widely appealing... the list goes on. And I built it all without using semantic shortcuts.

I really thought that I had a winner. The jury, unfortunately, did not.

I was disappointed upon getting the news—and then, for a moment, jealous of my print design peers. They could set type however they wanted, their design uncompromised by the kinds of limitations I have to consider when building websites. But the reality is that my primary area of practice is still new in the scheme of things, and many people don’t understand the challenge of balancing good design with sound semantics.

I had built my site using semantic code, meaning that content is structured into different levels (for example, H1 and H2 for major headers and secondary headers, P tags for paragraphs) and the structure of the document has meaning. My navigation is HTML-based. The markup is clear, and there’s not a lot of extra “junk” in my code.

Homepage banner and primary navigation for the author’s scrumptious Dozen Cupcakes website.

All of this is good because it allows the website to be indexed more easily by search engines. It also means that people with web accessibility issues will be able to read the page content more easily. It means that it degrades gracefully to work on a BlackBerry or cell phone, without serving a different set of content. It means readable page content loads almost instantly since it’s just HTML.

And it also means that the type can be a bit ugly.

While it’s true that the use of CSS to control the appearance of web pages has come a really long way since its origins in the mid-1990s, there are still some major typographic challenges that come with designing for the web. For example, while one can specify any typeface one wishes in CSS, the viewer needs to have that typeface installed on his or her machine in order to see what was intended. And while some technologies have come and gone that allow a font to be “embedded” in a webpage, none of them have been reliable on multiple platforms or in different browsers. If everyone is to get the same experience, more or less, web designers have but a limited set of typefaces to choose from: Arial, Courier, Georgia, Times and Verdana (and sometimes Tahoma and Trebuchet).

Verdana was designed for screen display at low resolutions (released in 1996). I, personally, can’t stand it for most applications now that most computers have surpassed the days of 600x400 screen resolutions. Times drives me nuts on the web. Though I have no problem with Courier, I don’t find it appropriate for most of my clients. Trebuchet and Tahoma are widespread, but not pervasive. So I’m left to choose between Arial and Georgia (which is the typeface you’re reading here and, in my opinion, an aesthetically pleasing one at that) for most applications. Not a lot of options.

Acceptable, unsexy, web-friendly fonts: (from top) Arial, Courier, Georgia, Times, Verdana, Tahoma and Trebuchet.

Personal preferences aside, the limited number of “universal” typefaces is not the only challenge. While CSS allows typographic control such as line height (a.k.a. leading), character spacing (a.k.a. tracking), transformation (i.e., uppercase, small caps, etc.) other web-based typographic controls are very limited. No real solution for kerning, just as an example.

The point is this: current typographic web control is rudimentary compared to the control designers have over print-based type. It’s better than it was in 1996, yes, but for 12 years to pass without major advances in technologies for web typography... well, that’s a long time.

With printing press technology around now for almost six hundred years, maybe it shouldn’t be a surprise that the web is taking so long to catch up. But in the meantime, one of the largest benefits of the web—that content can be meaningfully separated from design—could also be its biggest challenge to designers. Especially if semantics-based content is compared side-by-side to content developed without regard for structural semantics in print, Flash or a raster graphic.

Of course, I have no way of knowing why my site didn’t make the cut. Maybe the website really wasn’t all that great. Perhaps it was too simple. Was I just too close to the site to see it for what it was? Or maybe it isn’t me, and it had to do with the judges; maybe they had different ideas about what makes a website well designed.

In an exchange with author and educator Peter Hall, he suggested that the key to looking at the web might be to abandon the print analogy. I certainly think this idea helps to view HTML–based web content for what it is, but it won’t help pressure advances in technology that would allow the web to have a more sophisticated appearance while staying true to its roots in meaningful markup.

While web technology plays catch-up with hundreds of years of mechanically pressing ink to paper, (how) can web designers compete when it comes to comparing structured HTML side by side with Flash, raster graphics or print? Are there emerging technologies that will level the playing field?

And speaking of a level playing field, I can’t help but wonder about the parallels between the “amateur” designer and myself. A 13-year-old working out of her bedroom has access to very similar tools to the ones I use in my practice: an HTML editor, FTP application and browsers for testing. Though I have formal education and professional experience in web design, the tools I use to build a website have very capable freeware or home publishing equivalents, and the amateur designer can put his or her work online just as easily as I can. The nonprofessional’s typographic “failures”—ugly type that doesn’t follow the rules—may be no different on the surface than mine, even for all my knowledge and expertise. The only difference is that I know better.

But for all that knowledge, I also know that what the judges saw in the browser window was not what they were looking for. I can accept technology’s limitations for what they are, and I will just continue to build websites the way I believe I should. I only wish I knew why my work wasn’t good enough: was this technology’s fault or a personal shortcoming? I look forward to the day when I don’t need to ask that question.