Jeffrey Zeldman thinks so. In his essay, “iPad As the New Flash,” the author and standards guru argues that designers are now coding up device-centric user experiences at the expense of web standards, accessibility and the advancement of open web technologies.

Everything we’ve learned in the past decade about preferring open standards to proprietary platforms and user-focused interfaces to masturbatory ones is forgotten as designers and publishers once again scramble to create novelty interfaces no one but them cares about.

While some of this will lead to useful innovation, particularly in the area of gestural interfaces, that same innovation can just as readily be accomplished on websites built with HTML, CSS, and JavaScript—and the advantage of creating websites instead of iPad apps is that websites work for everyone, on browsers and devices at all price points. That, after all, is the point of the web. It’s the point of web standards and progressive enhancement.

He takes issue not with apps in general, but with the design choices being made by popular magazines as they rush to embrace the new shiny. His ultimate conclusion: “Masturbatory novelty is not a business strategy.”

The comments are enlightening, too. A few make the point that web standards like JavaScript and CSS can now be used to develop experiences that can be delivered both natively and through a browser. Another suggests this is just the Old World struggling to understand a new platform.

See also:

• Who Needs Flash?
• Flashy HTML5 Experiments Point to Web’s Future
• Video: Watch Flash Hand HTML5 a Beating on Mobiles

Twitter launched a full redesign to its website Tuesday, showing off changes that lead Twitter.com away from its humble stream-of-updates past and towards a more interactive, app-like future.

The new Twitter went live to a select few users Tuesday afternoon and began rolling out to everyone else Wednesday. If you don’t see it yet, you will soon.

The website now has a new two-panel view. Your familiar stream of tweets runs down the left side. On the right side is a dashboard of sorts, where you can see recent activity from your followers and the people you follow, trending topics, and the list of people you might want to follow.

Click on a tweet and it expands in the right panel. There, you’ll see rich media like photos and videos, associated conversations, recent tweets by the author, and mini bios for any other people mentioned in the tweet.

Overall, the update plays on features found in popular Twitter client apps like Tweetdeck and Seesmic, and it looks quite a bit like the official Twitter app for the iPad. Somewhat like those apps, you can dive right into videos or photos without leaving the Twitter website, whereas the old site required you to leave the site or launch links in new browser tabs.

Scrolling in the timeline on the left panel is infinite. New tweets keep loading at the bottom as you scroll, so you can just keep cruising backwards into time as far as you’d like.

When you expand a tweet by clicking on it, if there’s a video or a photo from a supported site (YouTube, Vimeo, Flickr and TwitPic were all included in Tuesday’s launch) it shows up nice and big. Videos play right there, and Flickr photos are accompanied by thumbnails to the rest of the photoset, if there is one. You can choose to see embedded photos and videos from only from people you’re following, or from everyone.

Images, videos, maps and retweets are all carried over to the new individual tweet pages. “People can much more quickly grok the context of a tweet,” Twitter CEO Evan Williams said at the launch event Tuesday.

To send a new tweet, you can either use the old box, still in its familiar location, if you’re on your home page. Or, if you’re elsewhere in the system, you can click on the little icon up next to your user profile picture to launch a floating window.

Something else very appy — Twitter has incorporated keyboard shortcuts.

Keyboard shortcuts are definitely a geeky power user feature, but ask anyone who uses them in Google Reader or Gmail and they’ll tell you they can’t live without them. In fact, the keyboard shortcuts are very close to those apps.

@mentions are now accessible from a tab at the top of your timeline:

As are retweets:

There’s a new search box at the top of the page. Run searches and you can save them (click the “Save this search” button up top) to keep track of new results. Saved searches will then live in a tab next to Retweets at the top of your timeline.

Lists are handy — I keep two or three that I browse every morning to catch up on tech news. Twitter has moved your lists into the last tab at the top of the timeline.

The redesign uses some cutting-edge web technology, including LABjs to speed things up and jQuery for the animated, Ajaxy twiddly bits. Also: the awesome Modernizr library, which checks your browser’s capability of handling different HTML5 doo-dads and adjusts the website’s code accordingly.

These changes show Twitter extending a big juicy lollipop to users — by providing people with a more rich experience directly inside the browser, there’s less of a reason to go download an app. This is bound to cheese off a good number of developers who have much blood and sweat (and cash) invested in their own Twitter client apps and web experiences. However, there’s still a place for those apps — Twitter has built this new interface on top of its own API, which means that any capable developer out there can do something very close to this design, or improve on it, on their own.

One big caveat: Twitter has the power to bypass its API rate limit of 20,000 requests per hour that it enforces for third-party applications. Only Twitter and selected partners can pull more tweets than that. These rates will change as Twitter grows, especially now that the service has got over 90 million tweets per day to play with.

Also, it’s doubtful this update will coax users away from their favorite apps.

Many people who use the website to tweet — Williams says 78 percent of active users have used Twitter.com in the last 30 days — will likely adapt to this update rather than reject it and run to a different experience, like a Tweetdeck or Seesmic. It exposes much more information than they’re used to, but by and large, the changes are useful and add more contextual value than visual clutter.

So for people who have only ever used the old Twitter.com, or even those (like me) who use apps occasionally but heavily favor the website, this is a radical change, but a positive one.

Those endeared to their third-party apps will probably look at the new Twitter.com and say, “Huh, neat, looks more like my favorite app than the old site.” Then they’ll go back to their app and tweet about it.

What do you think of the redesign? Tell us in the comments.

See Also:

• Does OAuth’s Complexity Alienate Small Apps?
• Twitter Moves to OAuth: The OAuthcalypse Is Nigh
• Twitter Now Lets You Automatically Follow Your Facebook Friends
• So Tweet: Geek Couple Plans Twitter Wedding
• Jurors: Stop Twittering

Huge CSS files can gunk up your page loads, creating annoying wait times for your readers and (if things get really bad) even driving people away before the page fully loads.

The trick to avoiding breaking your user experience is to make your CSS as lean, clean and fast as possible. There are tried and true techniques for speeding things up, like using Gzip, or serving one or two files instead of dozens. There are also poor optimization methods you should avoid.

Today, we bring you an informative video from the recent 2010 O’Reilly Velocity conference on how to optimize CSS while avoiding some of the most common mistakes developers make. It’s especially useful for those of you with big CSS payloads. The first speaker is a little dry, but the fun picks up when Nicole Sullivan takes over about five minutes in.

See Also:

• Advice From the CSS Guru: Embrace Prefixes
• Got Slow Web Pages? Find Out Why With YSlow
• Dealing With Browser Differences in CSS 3

Overview

We’re all tired of waiting for web pages to download, aren’t we? To make sure that visitors to your site don’t get frustrated, we rounded up some in-house experts to help you make your pages faster ‘n greased lightning.

Pictures are worth a thousand words — especially on the web, where pages of text can download in the time it takes for a single image to load. Your images may be sub-zero cool, but if they’re too plump, few people will stick around long enough to see them. We’ll dig into tricks and optimizations to speed up your GIF, JPG, and PNG downloads.

Once you’ve learned the basics of shrinking your images, we’ll will walk you through the advantages of using CSS for your page layout. And, if you’re one of those people who insists on using tables, we’ll offer you a few choice hints on how to get those tables slim and streamlined.

After you’ve removed the bloat from your layout code and your images, you’ll learn how to cut needless elements from your pages. Hint: Start with all those links.

The series concludes with wise words about how to come up with benchmarks for speed and how to test your site using nothing but a stopwatch and a pencil.

Get started with with lesson 1

Ask any web designer about the use of typographic design on web pages and they’ll tell you the same truth: The web is a harsh, uninviting environment for the delicateness of fine typography. Along with the usual web culprit of platform inconsistency, the extreme low resolution of even the best current screens means type online can only allude to the geometry of the typefaces you’ve so carefully chosen and specified.

The Devil’s in the Display

The fundamental problem of online type has nothing at all to do with the Web. The problem — whether you’re building pages for a website, CD-ROM, Palm Pilot, cell phone, or museum kiosk — is the display. On a computer screen, at least at relatively small sizes, Helvetica is not Helvetica. The chunky pixels on a 72- or 96-pixel-per-inch screen can’t possibly match the subtle curves of type.

This means that for body copy, we can barely produce legible type, let alone make subtle stylistic distinctions. What we’re left with is the grossest conceivable control – straight versus slanted, static versus dynamic, old versus new, light versus heavy, serif versus sans-serif. While it will take radically-better displays to bring onscreen typography up to the standards of the ancient Romans, there are several techniques which do help somewhat.

Pushing Pixels

Anti-aliasing

The problem of translating curves to pixels can be mitigated in larger (i.e., display) sizes by a technique called anti-aliasing. Anti-aliasing is the process of tricking the eye into seeing smooth curves instead of jagged pixels by using colored pixels around the edges of letterforms. Because the pixels are intermediate in tone and color between the type color and background color, they have the effect of smoothing out the curves.

The two problems with anti-aliased text are:

1. it looks fuzzy, and
2. it only works with relatively large sizes of type.

When used with body sizes, anti-aliasing often only produces a mushy mess. An interesting secondary consideration for the Web is that anti-aliased text may appear more corporate or polished and less “immediate” than straight HTML text.

Hinting

At small sizes, there’s only so much that can be done to improve on-screen legibility and fidelity to the “real” typeface, and it’s done with a technique called “hinting.” Hinting is a method of tweaking the outlines of letterforms so that they match up as well as possible to the screen’s pixels in order to produce the closest possible – or at least less mangled – reproduction of those ideal outlines. Hinting information is included as part of a typeface, so it’s not something you’ll need to do yourself, but if you’re interested in the gory details, take a look at this Microsoft article on hinting in TrueType.

While the practice may be esoteric, the results of good hinting can be quite dramatic. Compare, for example, the following samples of the same text (more or less) set in the meticulously hinted Verdana as compared with Helvetica.

Now you know why the vast majority of commercial Web pages created in the last year use Verdana. (There’s a second, related, reason:Verdana, designed by Matthew Carter and hinted by Thomas Rickner, was originally designed as pixel-friendly bitmaps. Once those were just right, Carter made outlines from the bitmaps instead of the more-common practice of designing outlines and then trying to generate bitmaps. Another screen-friendly face is Georgia, designed and hinted by the same team.)

Pixelfonts

Another option, especially for really tiny sizes is to use bitmapped typefaces. Since they’re designed specifically as bitmaps, without curves at all, faces like Silkscreen and Mini7 don’t have the same problem traditional outline fonts have onscreen. On the other hand, because they’re designed to the pixel, they work only at the specific sizes for which they were designed. Still, an entire visual style has arisen from these tiny pixellated fonts.

Technologies

Even if display resolution wasn’t an issue, type online faces a second major problem:the familiar bugaboo of platform inconsistency. This takes several forms, including different browser and plugin capabilities and – most challenging – different installed typefaces. We’ll take a closer look at these issues as we discuss the various technologies for specifying type on the Web:HTML/CSS, GIF images, Flash, SVG, and Acrobat.

HTML and CSS

The current XHTML spec provides rudimentary font control with the FONT tag, which allows page authors to specify typeface and rough size, like so:

<font face="Verdana" size="3">

However, this technique, while widely practiced now, is currently being phased out in favor of Cascading Stylesheets. CSS provides significantly more control, which we’ll explore in depth a little later. However, as giving and wonderful as they are, even HTML and CSS have several problems in common. Perhaps the biggest headache arises from the fact that people viewing our meticulously crafted pages may be seeing them in a totally different font than we intended because not everybody has the same typefaces installed on their machines.

Embedding

But, you protest, we can just embed the fonts. And we certainly can, and probably should, but we will still have to assume that a significant portion of our audience won’t ever see them. Probably the two biggest reasons more people don’t embed fonts are that the tools have really confusing interfaces, and we still have to design around the possibility the fonts won’t be downloaded. This paragraph, for example, is set to be displayed in Gill Sans and I’ve embedded the font, but many of you will see it in the default font for this page instead (which probably looks a lot better in this case). For the full scoop on font embedding, check out Mulder’s excellent tutorial.

The Shotgun Approach

If we can’t fully rely on embedded fonts, we’re stuck with guessing what our viewers might have installed. Luckily, we have a few techniques to help us. First off, the HTML FONT tag and CSS font-family property allow us to specify a list of faces, such as “Verdana, Arial, Helvetica”. The browser will display the first typeface in the list which is available.

Next, we can make educated guesses based on default Windows and Macintosh fonts and the fonts installed by recent versions of Web browsers. Microsoft has a page listing some commonly installed fonts (and not only Microsoft ones). The default fonts are so limited, in fact, that we see the same strings over and over on Web pages:”Verdana, Arial, Helvetica”, “Georgia, Times New Roman, Times”, “Courier New, Courier”.

Commonly-installed typefaces on Macs and PCs

MS Serif

Book Antiqua

Times New Roman

New York

Palatino

Times

MS Sans Serif

Arial

Trebuchet

Geneva

Helvetica

Chicago

Generic Families

Finally, we can use generic family names – ‘serif’, ‘sans-serif’, ‘monospace’, ‘cursive’, and ‘fantasy’ – to tell the browser to use the closest available face. (I have to take issue here with the absurd notion that “fantasy” should be one of these five core generic families – that one must have been added during some after-hours partying over at the W3C.) Finally, keep in mind that, as put in the CSS 2 spec, “Generic font families are a fallback mechanism, a means of preserving some of the style sheet author’s intent in the worst case when none of the specified fonts can be selected.”

“Verdana, Arial, Whatever”

So, if you want a sans-serif face, you just plop in “Verdana, Arial, Helvetica, sans-serif” and you’re good to go. If people look at your site and don’t have Verdana installed, they get Arial or some other sans-serif face and we can all move on to reading your brilliant article about collecting toy robots. Right? Well, yes and no. The mechanism works fine, but shoot – if all sans-serif faces looked the same, there would be no point to my writing the whole first part of this article. A second issue – especially important for body type – is that, as we’ve learned, different typefaces at the same point (or pixel) size can appear to be quite different sizes. Indeed, the CSS 2 spec addresses this problem with the font-size-adjust property and also includes a detailed algorithm for more specific font-matching, so we’ll still have degradeability but with at least some more control over the actual shape of the letters rather than their membership in hopelessly broad families like “sans-serif” and “serif.”

As a side note, there is a particularly funky hack for detecting installed fonts. It involves using JavaScript to compare the relative sizes of a layer of text set in the default face with one set in the face you’re testing for. It’s fairly ugly, but works surprisingly well. Unfortunately, there’s not all that much you can do with that information once you have it.

When is a Point Not a Point?

Type is traditionally (i.e., in the print world) measured in a unit called a “point,” which is 1/72nd of an inch on paper. But screens are based on pixels, rather than points. On the original Macintosh, there were close to 72 pixels per inch on the screen, so points and pixels matched up quite nicely, thank you. But now, displays and resolutions vary widely and Macs and Windows machines make significantly different guesses about them. Without getting into the gory details, type specified in points (or any point-based measurement) will appear larger on a Windows machine than on a Mac.

One solution is to conditionalize your type sizes for different platforms if using CSS or HTML. Another is to use the CSS “px” (for pixels) unit, which will force everything to the pixel grid. The primary drawback is that text set in pixels will generally foil user-defined text sizes. This can cause usability problems, especially if you’ve chosen particularly small sizes. It also may cause printing trouble (if the printer tries to translate your pixel sizes into points – more on CSS and printing in a moment). But for now, the alternatives may be worse.

In HTML, all we can specify is family and a rough measure of size. With CSS, however, not only can we specify exact size increments, but we can control such crucial properties as line-height, word-spacing, and letter-spacing (for more on using these properties, see lesson 3 on word- and letter-spacing and line-height). Line-height alone goes a long, long way to improving the readibility of a Web page.

Another advantage of CSS is the ability to specify different stylesheets for different output devices. The most obvious example is to include a separate stylesheet for printing a page (specifying different typefaces, perhaps, or using points rather than pixels for sizing), like so:

 <style type="text/css" media="print">

 .someClassName { font-family:Bodoni, Georgia, serif; font-size:10pt }

 </style>



 <style type="text/css" media="screen">



 .someClassName { font-family:Georgia, serif; font-size:12px }

 </style>

or, linked, like so:

 <link rel="stylesheet" type="text/css" media="screen" href="screen.css" />

 <link rel="stylesheet" type="text/css" media="print" href="print.css" />

Finally, I wanted to point out what I see as a big problem with using CSS/HTML for specifying type:Designers still lack control over anti-aliasing, especially in display type. Depending on your visitor’s particular operating system and settings, type will either be anti-aliased or not. You, as a designer, have no control, which is a darn shame because, as you now know, anti-aliasing doesn’t make sense for all typefaces at all sizes.

GIF Images

You may think that the lack of control over the way type displays on screen is no big deal. You can just make all your type out of images – GIFs or JPEGs – right? Well, yes and no. Using images to specify type looks at least as good as anything else onscreen and can be seen by almost all browsers, but it also introduces a number of serious problems.

The first problem is that images take up more file size than plain text, which can lead to slower display of your page. Related to this is the issue that each image (and a single page can have many if each header or navigation element is treated as an image) will require a separate server connection, again slowing down the time it takes for your page to display.

Besides speed issues, text in images isn’t selectable or copyable. And it’s not viewable by text browsers such as Lynx or screen readers for blind Web surfers. The workaround is to religiously use the ALT attribute of the <img> tag, which you should absolutely do. (If you’re not sure what to write, there are plenty of detailed ALT text guidelines on the Web.) Finally, text in images is fixed in size, which means it cannot scale along with non-image text on your page.

In addition to its considerable, though not insurmountable, usability problems, image text can be a pain to manage. Changing text contained in an image requires an image-editing program and the ability to use it, often the organizational province of a graphic designer, while plain text can easily be changed by a copyeditor or other member of a Web production team. Similarly, a change in visual treatment requires changing all images on a site. This is especially significant on a large site where a single change may occur across many images. By contrast, CSS-styled text can be changed simply by editing the appropriate style rule. Finally, text in images is not so easy to generate dynamically (although it certainly can be done). The bottom line is that images are not generally appropriate for personalized portions of a site.

Where images do make sense for text is in navigation or title treatments, where carefully specified and anti-aliased display type can make a site feel much more polished and expressive than jagged default HTML type. Just make sure not to forget about ALT text and consider using plain text if you have a large number of items, such as the navigation on a large news site like CNN.

Flash

The reason images are so wasteful of bandwidth is that they’re based on pixels rather than a more efficient method of describing visual information, such as [[Reference:Vectors | vectors]. So it stands to reason that a vector-based way of rendering type might make more sense for the Web. The most obvious current choice is Macromedia’s Flash.

In terms of type, Flash offers several advantages. The first is file size, as you can see in the following example:

Flash:548 bytes

Gif:1,459 bytes

As you can see (assuming, that is, you have the Flash plug-in, which we’ll discuss later), the GIF is almost three times as large as the Flash version. Since Flash is all based on vectors, in fact, the larger the type, the bigger the file-size savings. Double the size of the type, and the Flash file will still be only 548 bytes. The second advantage (as you can see above) is selectability. You should be able to select the text in the Flash example and then copy and paste it. Finally, Flash text can be pulled from an external source – an XML file or a Web server for example – which means both that content management is less a problem than with image files and that text in Flash can be dynamically generated, which as I’ve mentioned is relatively difficult using an image.

For static text in Flash, there’s no need to embed the font as it will be saved as outlines. For dynamically updated text, Flash supports embedding of fonts, either an entire font or specific glyphs. As with CSS font embedding, the font data can be saved as a separate file and linked from multiple Flash movies. It’s also possible to tell Flash to handle type similarly to how HTML and CSS do, by using “device fonts,” although you’ll be limited to the generic groups (‘_serif’,'_sans’, and ‘_typewriter’). And don’t forget, with Flash, you can make your type dance and twirl and fade in and out. I’m not saying you should, just that you can.

Trouble in Paradise

But Flash has problems of its own. One of the big ones has to do with anti-aliasing. The trouble is that Flash has no ability to selectively turn anti-aliasing on and off. Either everything in the movie is anti-aliased or nothing is. It sure would be nice to be able to use, say, 10pt Georgia for big blocks of text with no anti-aliasing and still have nice anti-aliased 36pt titles. Are you listening, Macromedia?

Another significant problem is that Flash files included on your pages won’t get printed along with the rest of the page. Flash has an internal print mechanism, so you can add a print button to a standalone Flash site, but that won’t help with Flash embedded along with HTML in a Web page. If you print this article, for example, you’ll see only empty boxes where the Flash samples should be.

Then, of course, there’s the fact that Flash is a plug-in rather than a “native” Web language like HTML. This is a legitimate concern, but at this point, after years of browser manufacturers forcing proprietary capabilities on us while ignoring established specifications (like CSS), I’m not sure what’s so “native” about HTML and CSS. And Flash is quite widely distributed, with Macromedia claiming over 90 percent “penetration” worldwide. Still, not everyone who visits your site will have the plugin, let alone the latest version. So you’ll want to consider whether you need to have a separate version of your site for non-Flash users. Recent versions make this more feasible by allowing you to store content as XML, readable by Flash and relatively easily convertible to HTML for accessibility.

Finally, many people have pointed out glaring usability problems in Flash movies, often attributing the lack of usability to Flash itself. It’s important to understand that many of the common problems (such as long intro animations, obfuscated navigation, and frustrating, non-standard scrolling mechanisms) are due to poor design rather than some inherent aspect of the authoring tool. On the other hand, Flash does have some definite problems, such as its inability to respond to the browser’s back button or to allow the user to bookmark a specific “page” in a Flash movie. Many of these issues can be overcome with good interaction design – the back button is less of a worry, for example, if you don’t force your visitors into a navigational dead-end – but they may require extra attention. For more on Flash usability, take a look at Macromedia’s Flash accessibility pages or Flazoom’s usability section.

If you’re new to Flash and want to learn how to use the darn thing, visit the Flash Tutorial for Beginners. For more on pixels and vector graphics, take a look at Web Graphics for Beginners.

SVG

SVG, like Flash, is a format for describing vectors. In fact, you can think of SVG as a sort of W3C-sanctioned version of Flash, although there are some important differences, most notably that SVG data exists as plain text, rather than in a binary format as does Flash, and that that text is formatted as XML. In fact, once you get past all the contextual stuff like document type declarations and so on, SVG is a pretty straightforward way of describing shapes:

<rect

x="100" y="100"

width="400" height="50"

fill="#33cc33"

stroke="#000000" stroke-width="2"

/>

Much of the promise of SVG lies, in fact, in its promise. As it exists today, it can only be viewed by people who have installed the Adobe plugin. OK, there are lots of SVG viewers out there, but I’m talking about regular people, not geeks who install development applications. But the idea of being able to handle vector graphics side-by-side with HTML and XML is quite powerful. For animations, it remains to be seen if SVG can compete with Flash, but for static type, SVG could be a godsend. SVG, like Flash, includes several methods for embedding typefaces.

I want to point out something here:Flash is a relatively mature authoring environment which happens to output movies in a particular binary format. As such, it has a great advantage over SVG, no matter the benefits of SVG’s strict XML format. Right now, this is probably the most important distinction – aside from plug-in distribution – between the two. This doesn’t mean that SVG won’t have its own authoring tools – it will. Indeed, Illlustrator 9 already supports SVG and LiveMotion eventually will as well. Or, just as likely, we’ll soon use Flash to generate SVG.

There’s growing support for SVG on the viewing side, including both Web browsers and mobile devices. It seems fairly safe to say that either SVG will be a usable part of our lives relatively soon or, if not, that Flash and SVG will converge enough to make the distinction moot.

Acrobat

And then there’s Acrobat, an entirely different animal. Instead of operating within a Web page, Acrobat files operate in their own self-contained universe. This means on one hand that you’d never use Acrobat to make page titles for a Web page. On the other hand, Acrobat promises precise control over the design of a page. The key word here is “page.” Think of Acrobat as an excellent way of distributing paper-like pages over the Internet.

Acrobat files will print exactly as authored, so they can be great for publishing reports or other documents that require graphic and typographic precision. On-screen, however, they’re more than a bit clunky to navigate, often seeming either a bit too large or a bit too small for comfortable reading. Accessibility can also be a problem, although Adobe has done quite a bit to address this with the latest release (Acrobat 5) and by providing tools like their Acrobat to HTML converter. Like Flash, Acrobat requires a browser plugin.

Finally, despite free and paid converters online, you’ll likely want to invest in the full version of Acrobat for satisfactory control over your output.

Resources On the Web and In Print

Whew! For a brief introduction to typography online, that’s a whole lot to digest. But now you hopefully know enough to choose and set type with confidence, and you can work around some of the problems of using type online. If you want to learn even more, I encourage you to explore the following resources I’ve included below.

Selected resources

Type foundries

• MyFonts.com (MyFonts.com is a Reseller of typefaces for many different foundries.)
• Adobe
• AGFA-Monotype
• Bitstream
• Emigre
• FontBureau
• FontShop
• House Industries
• ITC (International Typeface Corporation)
• Linotype Library
• P22
• Storm
• T-26
• Free fonts:there are loads of sites offering free fonts for download. Many of them are quite nice, but many more are relatively shoddy, either in design or in quality. In general, you’re best off buying a small number of high-quality fonts from a reputable source. This may also encourage you to use fonts to support text rather than the other way around. As [/webmonkey/html/96/46/index2a.html Kristin wrote] way back in ’96, when it comes to type, “Simple is almost always best.”

Books

• Typographic Design:Form and Communication
• The Elements of Typographic Style
• Stop Stealing Sheep & Find Out How Type Works
• A History of Graphic Design
• The End of Print
• Typography
• FontShop FontBook
• Precision Type Font Reference Guide

Magazines and other typography resource sites

• Web Page Design for Designers
• Microsoft Typography
• U&lc:Upper & lowercase Magazine
• FUSE
• Createivepro – fonts
• Robin Williams’ Type Talk
• Fontsite
• Type books
• x-height
• Lines & Splines
• Textism
• Typographer.com

A hopelessly incomplete list of type designers worth knowing

• Aldus Manutius
• Francesco Griffo
• Claude Garamond
• William Caslon
• John Baskerville
• Giambattista Bodoni
• Morris Fuller Benton
• Frederic Goudy
• Eric Gill
• Jan Tschichold
• Paul Renner
• Hermann Zapf
• Adrian Frutiger
• Paul Rand
• Herb Lubalin
• Saul Bass
• Erik Spiekermann
• Susan Kare
• Neville Brody
• Matthew Carter

I encourage you to take some time and browse these resources. Pick up a book or two on type. Find a few designers whose work is appealing to you, and then check out their friends. But just remember, the best way to learn about type — or anything else in design for that matter — is by experimenting. So, after reading up and looking around for inspiration, pull out your sketch book or start up your favorite graphics program and do some sketches. And when you think you’re done, do some more. And before you know it, you’ll be a typography pro!

Suggested readings