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.
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.