Want a free year on Tuts+ (worth $180)? Start an InMotion Hosting plan for $3.49/mo.
Designers on the web have had a notoriously tricky time with typography. For one, most web designers aren't trained as "typographers" the way that most traditional graphic designers are. Another reason is that typography on the web just hasn't been around for more than about 15 years... and most of us haven't been designing for even half of that time.
As such, the most powerful new medium in the history of the world is woefully lacking in formal training for the single most important discipline that a designer can master: typography. This article is the first in a series that seeks to compile a compendium of serious web typography lessons.
Before we start - this intro article is part education and part editorial. It's intended to be an off-the-cuff post about some of the principles that web designers need to take seriously. I'll do my best to avoid making this a "10 obvious ways to improve your typography" type of article... we've got enough of those already on the web, and if we ever do decide to run one of those, we'll make sure we do it right. This series is going to be more about creating reasoned, logical processes for developing effective type systems rather than a smattering of random tips. First, we're going to face up to some of the cultural hurdles facing web designers.
Our Dilemma: A Lack of History
Let's face it, compared to the vast amounts of books and years of resources out there for print designers, the web has a relatively short experience with typography. We're a lot like teenagers with their brand new driver's license - lots of power and responsibility without a lot of experience to draw upon. Because the web is so young, designers have been left with one of two choices: 1) try to recreate a print aesthetic on the screen or 2) wander off into the great black void... hoping to discover web type perfection.
The problem with the first choice is that print doesn't translate directly to the web. The problem with the second is that it's a lot like throwing darts... sure, we'll have some successes, but it'll be at the cost of a whole bunch of flops.
Are there some amazing resources already out there the topic? Yes, absolutely... and I'll list them at the end of this article. But the simple fact remains that, for a young web designer hoping to cut his teeth on the topic, it's often hard to make heads or tails of the subject without spending countless hours scouring random blogs. In fact, part of the problem is that so much about web typography is presented as "subjective" information. The only guiding principle that most people can agree upon is that "type should be legible"... but after that, there's a whole lot of opinion and not much fact.
This brings me to my first "cultural" point for anyone who is serious about upping their web-typography skills...
Rule 01: Stop the Blame Game
Let's address the first real hurdle in between a designer and typographic greatness: Blaming something or someone else. If I had a dollar for every time I heard a web designer gripe over how browsers render type differently - or that some random content editor ruined his layout - or that a client simply refused to see reason, I'd be a hundredaire (the lesser known cousin of billionaire... c'mon, I don't know that many people!).
These are all what I call "occupational hazards" - you know about them when you get into the industry and you're going to encounter them on pretty much a daily basis until serious professional standardization settles upon the web (which I don't predict any time soon). I'm not trying to say that these issues don't exist (they do, and they are a pain in the butt), but to throw all of our typographic inadequacies upon the the back of Internet Explorer 6 or some random copy dude making $8 an hour is avoiding the issue.
The great thing is that a serious web typographer can work around these issues. Browsers can be tested for; Layouts can be made "idiot-proof", and clients can be
told to go to... gently instructed to see reason.
Rule 02: Own The Task of Typography
Back in the age of printing presses, woodblock letters, and hand set type, there was a clearly established pecking order for who was responsible for getting things done properly (typographically speaking) . Not surprisingly, that person was usually the guy that was elbow deep in black ink and the only person in town who knew how to use the massive contraption. Heck, in most towns, he might be the only guy who actually knew how to read, so you took his word for it when he told you how to lay out your publication.
Clients brought the content, printers handled the layout and design. No one screwed with the system.
Nowadays, it seems we suffer from a case of "too many cooks in the kitchen". Because everyone has access to Microsoft Word and a keyboard, designers have to wade through an ocean of "insta-typographers" during the design phase...
Don't get me wrong, receiving feedback from a client is a crucial part of the creative process... but it's not a substitute for actual, experienced decision making at the typographic level. That's your job - the designer. If you're gliding through a project, just waiting and hoping for a client to decide on a particular font or line-length, you might as well fire yourself. By doing this, you reduce yourself to little more than a body attached to a mouse.
I'll repeat myself just to be safe here - this doesn't mean you should become some surly jerk who scoffs at valuable feedback. What I'm trying to say is that if no one agrees to "own" the job of typography during a project, you're going to end up with mediocre, watered down, half-assed type that doesn't do justice to the fact that we have centuries of typographic research at our very fingertips. Laying out a column of text and hoping that some other designer, developer, or client will come back and make it look right is a cop out.
Be the designer, own the responsibility. Typography is your job.
Rule 03: Treat Type as a User Interface
When you think of a user interface, what do you think of? An iPod's classic scroll menu? The dashboard display for your car? Some sci-fi video game's HUD? Those are perhaps all examples of user interfaces... but I'd like you to reconsider what it means to web designers. Let's examine briefly the interface style trends over the last decade:
- In the early 2000's, web designers thought that a great user interface meant lots of brushed metal, pseudo photo-realistic buttons, and glowy letters.
- In the mid 2000's, web designers thought that a great user interface meant using glossy buttons, bright colors, and bubbly graphics.
- In the late 2000's, web designers thought it meant tactile textures, fake "desk" or notepad environments, and bold typefaces.
- Nowadays, we're fixated on "noisy" backgrounds, inner/outer stroke dividers, and white text-shadows.
These are all great fads (and yes, there are obviously plenty of great exceptions to these generalizations)... but consider some of the web driven brands that have existed through all of these years (and still refuse to die). Here - I'll show you what they look like:
Are any of these what you would consider as "great user interfaces"? Probably not... But they are all ridiculously successful (and like it or not, usable) designs. So why are web designers bending over backwards to create designs that look nothing at all like them?
My humble opinion: it's because our industry/trade is still relatively immature. We're all hoping to find the "next big style", so we purposefully shun designs that are boring but functional. We loathe the idea that something designed in 2005 still has users. We embrace the notion that by fluffing up our designs with difficult techniques and textures will somehow make them more usable.
Perhaps a better analogy is found in cars... We're all trying to design a typographic Ferrari when 98% of projects really just need a Honda Civic (or in some cases, a bicycle). As long as it works at getting people from point A to point B, it's fine. The second we begin changing the functionality of the site with our own fancy notions of what an "awesome user interface" should look like, we risk breaking the bike.
The simple fact of the matter is that plain old text, without all of the bubble effects, gloss, and other crap that we've thrown around it, is just as usable on it's own as if it were all styled up as if it were going to walk down the red carpet.
Why? Because text is the user interface! Before you grab the gradient tool, remember that - text is the interface. You can not have a usable interface without text being legible and meaningful. Web surfers will adapt to whatever stylesheet you throw over a design - but the core elements of a site (navigation + content) must work before anything else.
Side note: This concept of "text as UI" is originally attributed to Khoi Vinh - but I've had a hard time tracking down where he actually wrote about this - so you'll have to take my word for it.
Rule 04: Take CSS Seriously
Type always goes inside a layout, and layouts on the web never, ever exist without code.
The last rule that I'm going to address today is the actual stuff that makes up web typography: CSS. With well written CSS, your entire website should style itself in a logical manner - each page will look similar, creating a unified and consistent site presentation. With well written CSS, addressing multiple browsers and devices is possible. Heck, with well written CSS, you'll prevent hair brained copy editors from breaking your beautiful designs.
The point I'm driving at is this: if you fancy yourself a web designer, but you're really only good at whipping together Photoshop mockups, you're missing half of what it means to design for the web. Type always goes inside a layout, and layouts on the web never, ever exist without code.
I won't say much here because, frankly, I'm eager to start writing the first parts of this series - but I would like to end with a handful of links that you guys/gals can check out in the mean time. My goal for this series is going to be to compile an awesome compendium of real, hands-on web typography tutorials... but I'm going to be drawing on information from a variety of other authors, articles, and books. So, here's my list: