Bram Pitoyo, Etc., typography

@font-face Brings An Interesting Consequence To The Way You Read On The Web: An Editorial

“It Reads Like Butter” For The Web

Call me a purist, but in my line of work as a typographer (and rarely, type designer), I usually cling tightly to the most conservative of rules: readers will read best under the condition that they’re most used to. Here, I’m concerned about legibility and readability that impact the speed of reading. I often said that the more “it reads like butter” and the more the text can deliver the information within lucidly, the better I’ve done my job.

The nascent of @font-face—epitomized by the release of Firefox 3.5 that most of the web use and will upgrade to—means that designers and developers will take advantage of the many new CSS rules available to them, including @font-face. They will shortly embed more typefaces—those outside the Core Web Fonts collection—for reading.

However, all Core Web Fonts have been hinted for on screen reading, while many type families out there have, but not very completely. Hinting is a type design process that some have the skills to handle, and even fewer have to handle well. Most chose a scripted algorithm inside their font design program to hint: essentially autohinting.

There Is Hope

There are several good examples, by the way, of superbly hinted faces: Luc(as) de Groot’s Thesis Office, FontFont’s Axel and Mark Simonson’s Anonymous—but these are exceptions rather than a rule. There is also Microsoft ClearType Font Collection that comes bundled with Windows Vista, the upcoming Windows 7, Microsoft Office 2007 and Office:mac 2008.

If you’re setting type as headlines. Hinting instructions only apply at small sizes (usually between 8–12 px). In bigger ones, the characters render well enough because the pixel isn’t as constraining, so hinting isn’t needed. This means that type will always set well on bigger sizes.

It’s Inevitable

But the fact is, web readers have always used to reading onscreen texts set in Verdana, Georgia, Arial, Helvetica and Lucida Grande (the last two are if you’re on a Mac); so the question still remains:
When we’re faced with new font families, will we still read as well as we have been with Core Web Fonts?

Caveat: on the web, readers do tend to be more savvy at reading various type variations (sizes, weights, families.)

Advertisements
Standard
Bram Pitoyo, Etc., Interlude, Links, Presentation

If You Spent Most Of Your Workday Staring At The Terminal Window

—then it’s probably worth to make the letters you see in that window more legible, and the text more readable.

I’ll be doing a bring-your-own-laptop workshop at Open Source Bridge about this subject.

(And the best thing is, if this session sounds boring, there are seventy-some more interesting ones.)

Open Source Bridge is the first ever volunteer run, open source technology conference—based in the lovely Portland, Oregon. I am proud to have been a supporter (and helper at times) to this exciting initiative. You can be a supporter as well, by registering and/or booking a room, and donating (you can’t lose with a $2 minimum, in my opinion)

Buck back to the font business. What do you mean by making letters and text read better? you ask. You can read more about it here, but I’d rather give you more explanation here.

Legibility and readability is two different, but interrelated subjects. One concerns itself with how easy it is to distinguish individual letter. What makes an ‘a’ an ‘a,’ for instance? We claim that our eyes will instinctively know it when we see it, and know it when something looks wrong, but, really, what’s in an ‘a’ that makes it look like a proper ‘a’?

This will be addressed with many pretty pictures of alphabets and history.

Readability concerns the character set as a whole. For instance, a font that may possess legible characters—where every alphabet looks proper and distinguishable—may not be as readable because the reader can’t read it well, or fast enough. What’s the problem, then? Reductivist beware: it turns out that our eyes don’t read individual letters, but scan over the 1) letter’s top half, and 2) space between and inside the letters. This means that things like line length, work spacing, letterspacing (tracking), leading (line-height) and color all plays a role in deciding how effective you can read a piece of code.

This will be addressed with slightly less pretty pictures.

Finally, now that you know the principles behind what makes something read better, I will introduce you to tools to experiment and make your own. But making a whole font from scratch is tricky, you said, and I don’t really mind the current type that I’m using, except for a few characters. Not to worry, there is a trick to easily do this.

Oh, did you say that you want to make an entire pixel-based programming monospace font from scratch? That’s possible, too. This type of font is a good place to start designing from.

And we’re going to use open source software and free tools to do this. Bring your laptop. I’ll see you there.

Standard
Bram Pitoyo, Interlude, Links

Case Study: Making OakHazelnut.com Read Better [Updated with picture examples]

A blog post on OakHazelnut.com, before and after optimization

OakHazelnut.com is a working portfolio site of Amber Case: an amazing independent journalist, search engine and social media consultant. Her site is one that is a resource to the community, and thus is seen by thousands of readers every month.

However, because it contains ample amount of informations (a typical post weighs in at about 750 words) the site has to be easy to read. So easy that only the text that is absolutely necessary to the content shines, while other materials regress. Add the fact that she publishes an article every two days to this.

Readability and legibility is of further concern because, while the OakHazelnut.com’s ultimate goal is to get more subscribers, most readers still interact with its web interface, or at least use it prior to subscribing.

Objective and Challenge

As a typographer, my aim was to make OakHazelnut as easy to digest as possible. As a publisher, Amber Case needs a vessel that will, like Beatrice Warde’s Crystal Goblet, be robust enough to hold any content that she throws at it.

Right off the bat, I was presented with the challenge that the visual language of the site must stay as similar to the old as possible. This makes sense. After all, OakHazelnut.com has been known to use the same theme throughout its inception, GreenWave, and thus must remain consistent.

This means that tweaking navigation scheme is okay (and even encouraged if it can mimic those of other sites to encourage familiarity) but switching images, color scheme or number of columns around must be avoided, or done very subtly at best.

In addition to this, because the author installed many plugins and changed many lines of code already, shifting the structure of the CSS (ie. reorganizing classes) was not to be done, to avoid breaking the theme.

The many plugins installed at OakHazelnut.com

With these constraints in mind, I got ready to work.

The Four Step Process

1. Standardize Typography

The default GreenWave CSS specifies three different kinds of sans serifs, impeding consistency

The very first thing that I set out to do was standardize the font family used in the site. Many themes rely on using different families to distinguish content. This is fine, but only if done well Blogs have many layers of information that need to be distinguished from each other. For instance, a typical blog page may have:

  • Blog title
  • Blog description
  • Navigation
  • Secondary navigation
  • Blog post title
  • Post heading (h2 through h6)
  • Meta information
  • Body text

And in most cases, using one font family is enough to get the job done.

But if one would choose to use two, this is how one might group them. One font per group.

Group 1

Primary Information, one where you want the eye to go look at first. Ideally, you would be able to simply hover from item from item in this group and get the gist of the blog.

  • Blog title
  • Blog post title
  • Post heading (h2 through h6)

Group 2: Secondary

  • Blog description
  • Body text
  • Navigation

Group 3: Tertiary

Informations to be “read later” (in most cases, one would group them with Group 2)

  • Secondary navigation
  • Meta information

On Choosing Typefaces

Some fonts are better suited for one purpose than another. For example:

  • While Lucida Grande/Sans and Verdana looks and reads well at smaller sizes, it quickly loses subtlety and elegance when set as headlines (Lucida is more resilient.)
  • Helvetica, Arial, Times New Roman, and now Georgia, work equally well at relatively wide range of sizes, thanks to our habit of reading and therefore getting used to it over a long period of time.
  • Trebuchet MS, tend to be used prominently at large sizes but hadn’t found many uses in body text (even though it’s just as readable, this I don’t know exactly why.)
  • Others, like Hoefler Text, Baskerville and Didot, may be unsuitable to be set small thanks to the monitor’s low resolution
  • Others still, like Futura and Gill Sans, comes by default on Mac but never ended up getting used very much (the reason is obvious, for using a font that isn’t installed on 85% of the Windows-platformed systems does not make sense.)
  • Finally, Tahoma is face that comes with almost every computer, and one that I find to be of a fitting use in subheadline situations (the spacing is too tight on smaller sizes, yet the construction does no display subtlety at large sizes.)

Getting Into The Code

View GreenWave’s original CSS file.

View OakHazelnut.com’s CSS file.

Of course, then, even though I was forbidden to reorganize the CSS class and ID structures, I must in some ways put some order in its structure. Right off the bat, I noticed (code shortened to highlight important points):


body {
font-family:Trebuchet MS, Arial, Helvetica, sans-serif;
}
#menu_search_box {
font-family:Verdana, Arial, Helvetica, sans-serif;
}
#header_center_text #header_center_body {
font-family:Verdana, Arial, Helvetica, sans-serif;
}
#header_title span {
font-family:Verdana, Arial, Helvetica, sans-serif;
}
#menu {
font-family:Verdana, Arial, Helvetica, sans-serif;
}
#blog_right #sidebar h2 {
font-family:Arial, Helvetica, sans-serif;
}
#blog_right #sidebar ul li {
font-family:Arial, Helvetica, sans-serif;
}
#blog_right #sidebar li a {
font-family:Arial, Helvetica, sans-serif;
}
#blog_right #sidebar ul li ul li {
font-family:Verdana, Arial, Helvetica, sans-serif;
}
#blog_right #sidebar ul li ul li ul li {
font-family:Verdana, Arial, Helvetica, sans-serif;
}
#blog_right #sidebar ul li ul li ul li a {
font-family:Verdana, Arial, Helvetica, sans-serif;
}
#blog_left #blog_comm .comm_panel {
font-family:Verdana, Arial, Helvetica, sans-serif;
}
#blog_left #blog_comm .comm_text {
font-family:Verdana, Arial, Helvetica, sans-serif;
}
#blog_left #blog_comm #comm_post_form td {
font-family:Verdana, Arial, Helvetica, sans-serif;
}
#blog_left .item_class .item_class_title_text .date_month {
font-family:Verdana, Arial, Helvetica, sans-serif;
}
#blog_left .item_class .item_class_title_text .end_title {
font-family:Verdana, Arial, Helvetica, sans-serif;
}
#blog_left .item_class .item_class_text {
font-family:Verdana, Arial, Helvetica, sans-serif;
}
#blog_left .item_class .item_class_panel a {
font-family:Verdana, Arial, Helvetica, sans-serif;
}
#blog_left .item_class .item_class_panel a:hover {
font-family:Verdana, Arial, Helvetica, sans-serif;
}
div#footer #footer_text {
font-family:Verdana, Arial, Helvetica, sans-serif;
}

Notwithstanding the fact that Helvetica and Helvetica Neue should be specified in front of Arial whenever possible, and that mixing two sans serifs is generally not a sound principle to follow, specifying the same font-family set over and over again for very small levels of CSS class is simply redundant.

To remedy this, I did a Find-and-Replace run, deleted all occurrence of “font-family:…” and replace them with:


body {
font-family: "Lucida Sans Unicode", "Lucida Grande", "Helvetica Neue", Helvetica, Arial, sans-serif;
}
strong, em, b, i {
font-family: "Lucida Sans", "Lucida Sans Unicode", "Lucida Grande", "Helvetica Neue", Helvetica, Arial, sans-serif;
}
h1, h2, h3, h4, h5, h6, address {
font-family: "Lucida Sans", "Lucida Sans Unicode", "Lucida Grande", "Helvetica Neue", Helvetica, Arial, sans-serif;
}

These lines of code does much of the same thing that the redundant blocks above do with only the lines that are actually needed to do the job, and nothing more. Much better.

On Choosing Lucida

Note how I specified a different set of typeface to replace the default set that the WordPress theme had. Why did I chose an odd combination of Lucida Sans Unicode, Grande and Sans? And why did fall back on Helvetica Neue, Helvetica and Arial?

Technically, I used a solution from SixThings called “Lucida Hybrid.” Put simply, Lucida Hybrid aims to combine the best of:

  • Lucida Grande – only available on Mac, no italic, renders beautifully
  • Lucida Sans Unicode – available on Windows, no italic, renders beautifully
  • Lucida Sans – available on both platforms, has italic, but the normal weight renders poorly at certain sizes

Typographically, I used the Lucida family because it’s the same face that Mac OS X uses to set the UI texts—bringing familiarity, therefore allowing the typography to disappear and content to shine. On the case that a Window user don’t have this family, the CSS will roll back to Helvetica Neue first, then Helvetica, and, if nothing else is possible to use, Arial. Again, Helvetica and Arial are two faces that computer users are used to seeing.

2. Enhancing Body Text Readability

My next objective is to soup the body text up. GreenWave’s default CSS specified:

#blog_left .item_class .item_class_text {
color:#8a8a8a;
font-family:Verdana, Arial, Helvetica, sans-serif;
font-size:11px;
line-height:20px;
}

This is the right idea. Any small type on low resolution display must be generously leaded to avoid clumping, and Verdana reads well at 11 pixel. However putting an #8a8a8a (roughly 50% grayscale) color on a white background provides too little of a contrast for such ample amount of texts to read well.

My solution:

#blog_left .item_class .item_class_text {
color:#262626;
font-size:12px;
line-height:20px;
}

On a lit display like a monitor, specifying black (#000) on white (#fff) is too jarring for the eye. I avoided it by using a dark shade of gray. The same solution is used in most books that are printed in slightly tinted, “egg white” paper, because reading a bright white, glossy paper is not easy.

Note how I kept the line-height generous, but increased the font-size by one pixel.

3. Standardizing Behavior

Next, I looked at how the links behave. Notice how, by default, the theme behavior specified light grey for body texts and dark grey for link colors. This is very helpful, but note how hovering at the link does not actually change it in any way. It remains dark grey. No highlight. No underline. Nothing. To aid comprehension, links behavior should be standardized:

  • Every link color inside the body of the blog, if put on top of a white background, should be colored green. This includes regular and meta information links. Exception: Post Titles, because it’s big enough to be distinguishable from the rest of the text.
  • Every link color, if put on top of a non-white background, could be colored white or grey, depending on the needs and color contrasts
  • Every link put on top of a white background, when hovered, should be colored in light green, then underlined. Exception: Post Titles, because underlining a text with small leading isn’t pleasing to the eye
  • Every link put on top of a non-white, when hovered, could keep its color or switch to light green, whenever appropriate and beneficial to page contrast, but they should always be underlined.

4. More Tweaks

The last step is to change more colors, increase more leading and decrease more type sizes. To regular readers, the tweaks are subtly visual at best; but remember: the more readers voraciously dive into the material itself without noticing how the type was set (except on highlighted elements), the more the typography had succeeded.

A fuller comparison of an OakHazelnut.com blog post, before and after typography treatment

Ready To Make Your Site Or Blog Read Better?

Standard
Bram Pitoyo, Etc., Interlude, Presentation

Beer And Blog: How To Make Your Blog Read Better

UPDATE: The presentation is now available for viewing and download.

This Yesterday afternoon, Justin Kistner Direct Messaged me, saying that he had a spot open for tomorrow’s Beer and Blog. He then asked if I have a topic that I would like to share.

And I thought: typography for the web, of course

So if all goes well, tomorrow’s Beer And Blog presentation is going to cover best practices to make your blog read better. It’s going to be light on the technical and heavy on the tips (and visuals.) We’ll discuss simple things that you can do to improve legibility and readability.

What things? You know, like selecting the right typeface for the job and adjusting it accordingly. And, who knew, maybe you’ll learn a thing or two about our reading behaviors, too.

The most subtle typographic difference can make your next great post read like butter.

Are you ready?

Standard
Bram Pitoyo, Links, Typeface Identification Around Portland

The First In A Series Of Posts In Which I Will Attempt To Utilize My Typography Skill To Identify The Typefaces That Ephemera Around Portland Is Being Set In

Starting with an advertisement I took on the 82nd and Division bus shelter, then two pictures I shamelessly stole from a brilliant local blogger, Lelonopo, on her Signs Of North Portland series.

Here we go.

Smokey Poster Commits Typographic Sin

Verdana

The Portland Ice Cream Company by Lelonopo

Playbill

The corner that gentrification forgot

Cactus Flower

Good night.

Standard