Fungible Convictions

You and the person sitting next to you have a friend, Donna, who has asked you two to help design a blog for her existing website. Donna feels a little in over her head, and all she knows is that the font needs to be Verdana—the same as the rest of her site—and that she’s worried no one will read her entire posts because she tends to write very long posts…especially not her father, who says he skims web content because he thinks the type is always too small.

Your task is to reassure Donna by filling out these CSS statements so they will beautifully render the typography for her blog’s main text block. (Assume it is just the text block, with no sidebar or other divs.) How would you explain to Donna your decisions? Without knowing anything else about the rest of Donna’s website, what might you look for to make sure your blog typography fits with the site as a whole?*

/* The main text div */
#main-text {

}

/* The blog post's headline */
h2 {

}

/* The text of the blog post itself */
p {
font-family: Verdana, sans-serif;

}

*If you’re not comfortable enough with writing CSS from scratch, simply describe your thinking about what you would do with the main text block, heading, and paragraph text.

Now we’ll look at some of the basic typographical issues for the three main CSS “levels”: pages and paragraphs, headers, and individual words

Page/paragraph level

As mentioned in the previous post, page- and paragraph-level typography mainly has to do with width considerations. You’ll want to obsess about how wide your lines of text run: too narrow and you may push a lot of text below the fold, resulting in a lot of scrolling; too wide, and your readers’ eyes get tired.

In print typography, it’s called “choosing a comfortable measure”. Traditionally, you want to keep lines limited to no more than 75 characters, with 66 characters being considered optimum. But on the web, it can and should be up to the user.

Therefore, take advantage of adjustable widths. You can set your text box width to be 50%, meaning no matter how wide the user sets their screen, the box will always fill 50% of it, with measures adjusting accordingly. Or you can set your text box to, say, 33em, meaning the box will always accommodate approximately 66 characters, with the box itself changing in size as the user makes adjustments.

Next, for the same reasons, obsess over your line-height. (In print typography, leading.) Each line needs a little space between the lines above and below, but too much or too little strains the eyes, especially for longer texts. It should suit the typeface, text level (body, heading, etc.), and measure. This CSS for example…

p {
font-size: 12pt;
line-height: 1.25;
}

…results in type that is 12pt with a breathable, comfortable line-height, 1.25 times the font-size, and stays 1.25 times the size no matter how the user resizes the type.

Having a stable line-height also gives you the chance to square up lines of body text with lines of sidebar text, no matter the font-size.

Header level

Similar in thinking to using a good measure, establish a good rhythm with your headers.

Book designers will tell you, “Don’t compose without a scale,” meaning everything—everything—has to be in rational proportion, especially headers. For example, if the default body text happens to be 16px, you should set your headings and paragraph text to sizes in proportion to 16px:

body { font-size:100%; }
h1 { font-size:2.25em; /* 16x2.25=36 */ }
h2 { font-size:1.5em; /* 16x1.5=24 */ }
h3 { font-size:1.125em; /* 16x1.125=18 */ }
h4 { font-size:0.875em; /* 16x0.875=14 */ }
p { font-size:0.75em; /* 16x0.75=12 */ }

Word level

At the word level, there’s actually very little agreement on best practices.

Historically, web designers argued that sans serif typefaces were all you should use for main text. This was because screen resolutions couldn’t quite render serifs cleanly enough—they were blurry or pixelated and generally looked worse than cleaner sans serif typefaces.

But with higher resolution screens, this isn’t as much an issue. It’s up to you and your readers’ needs.

However, there are some lesser-known CSS properties that you’ll want to take advantage of, especially for your headers. Pre-installed typefaces like Times New Roman, Arial, and Verdana are versatile but not perfect and can often benefit from tweaks at larger or very small sizes.

For example…

p {
word-spacing:0.25em;
}

h1 {
word-spacing:-0.125em;
}

…will result in words in a paragraph that are proportionally spaced out slightly more than default, while it will pull words in top-level headings slightly closer together.

The same can also be done with letter-spacing CSS property but should only be applied to large headings or with special combinations of letters such as an upper-case T preceding a lower-case o.

Last, there is the text-transform property. It should be used to define text that you always want to be uppercase, always lowercase, or always have their first letters capitalized.

Reference:
http://webtypography.net/Rhythm_and_Proportion/Horizontal_Motion/2.1.2/
http://webtypography.net/Rhythm_and_Proportion/Vertical_Motion/2.2.1/
http://webtypography.net/Harmony_and_Counterpoint/Size/3.1.1/
http://webtypography.net/Rhythm_and_Proportion/Horizontal_Motion/2.1.1/
http://webtypography.net/Rhythm_and_Proportion/Horizontal_Motion/2.1.8/

Everyone in this class has a basic knowledge of CSS–cascading style sheets, which is the code, kept in a .css file, that, among other things, tells every bit of text on a website how it should look. An example CSS statement for text in a paragraph could look like this:

p {
font-family:"Times New Roman";
font-size: 20px;
line-height: 200%;
color: #333;
text-align: center;
}

Or in plain English:
For all paragraphs on this page, set…

• the typeface to Times New Roman
• the type size to 20 pixels
• the line spacing to double (so, 200% is the same as double-spacing)
• the text color to a medium gray
• and center the text

Choosing your measurement for text
But what many people don’t know is exactly why, in that statement, you would choose pixels as the measurement for your font-size when “em”, “pt”, a percentage, or even a keyword such as “xx-small” could also be used.

So when should you use pixels (px), points (pt), ems, percentages (%), or keywords in your CSS?

The answer has to do with context.

Pixels are absolute measurements, so that in a cascading stylesheet, pixels don’t “cascade”. If you set a parent element (p, for example) to be 12px and a child element (p > p.smalltext, for example) to be 10px, they will be 12px and 10px, respectively, on the nose.

But ems, percentages, and keywords are relative measurements. If p happens to be set in absolute terms like 12px but p.smalltext is set to .8em, p > p.smalltext will be .8 of the size of p (9.6 px). The same goes for percentages.

Why would you use relative measurements like em and %? Because it keeps all of the text in relative balance no matter how it gets resized by the user.

Choosing your measurement for block elements
Text is one thing. But these measurement types play a crucial design and usability role with block-level elements—divs mostly.

It would make lots of sense, and is a best practice on the typical blog design, to have the main-text div have a width that changes as the user resizes his or her screen. (We’ll talk about why this is a best practice in a future post.) You can’t do that with px, but you can with ems and %.

But for the sidebar, it does make sense to keep it a specific width—something you can only do with px.

And to touch briefly on points (pt), they should be used exclusively for your print stylesheet. It’s what tells the printer what size you want the text to be when a webpage is printed in hardcopy, and you don’t want the user to muck with how text is displayed in print.

So to sum up, when choosing pt, px, %, etc., each element of your webpage has its own needs, and you want to choose the right thing for that specific element.

Reference: http://css-tricks.com/css-font-size/

When I started this blog several years ago, it coincided with a professional study of print design—which meant I got more interested than the average geek in type-level CSS and options/standards for web typography. It’s to the point where I’ve now volunteered to teach a 2-hour course later this month during MIT’s Independent Activities Period (IAP) on typographic principles for the web.

Typography for the web: Principles and tools
Andrew Whitacre, Communications Manager, CMS/C4FCM
Tue Jan 26, 02-04:00pm, 2-142

Enrollment limited: advance sign up required (see contact below)
Signup by: 25-Jan-2010
Limited to 20 participants.
Single session event

There’s nothing better than good typography to make your website more readable, searchable, and beautiful. This class starts with the first principles of typography and applies them to the web. By the end of the class, you will know 1) how to choose the right font for the job, 2) how to design your text beautifully without sacrificing accessibility for the visually impaired, and 3) what tools are available to expand your skills and make your type-on-the-web life a whole lot easier. This class presumes basic knowledge of Cascading Style Sheets (CSS).
Contact: Andrew Whitacre, Communications Manager, CMS/C4FCM, awhit@MIT.EDU
Sponsor: Comparative Media Studies

When each person registered (it’s up to about a dozen folks now), I ask them to describe what they hope to get from the class and if there’s anything in their work they could especially benefit from learning about. (IAP courses are open to anyone at MIT—students, faculty, staff, anyone.) So I’m going to write up a set of blog posts here thrashing out my thoughts to their responses. One person wants to know about picking the right font for the job, another wants advice on marketing considerations, and everyone wants guidance on CSS.

I think they’ll be surprised to find out how much there is to know about accessibility—everything from proper contrast for older users to fluid widths to accommodate various screen sizes. I’ve budgeted twenty minutes for that section, but I can easily see it running over.

Anyway, overall this should be a blast. The posts coming over the next couple weeks should be interesting as I teach myself what I need to teach on the 26th.

It’s tough to describe the awesomeness of the conference we just ran at MIT. It was exhausting, yes. But I designed/printed the conference program, helped set the schedule, managed 200 attendees, kept an eye on an intern, and got to work with some incredible colleagues.

Based on the syntax of that last sentence, you can tell I’m exhausted. But I got to meet some folks that I’ve admired for a long time, such as Dan Gillmor, and got to promote the 2009 Knight News Challenge winners.

I’m conflicted. This conference was the last big set of tasks from now until the fall, so I’m glad I can rest a bit. But it was why I wanted to work with MIT’s Center for Future Civic Media—a chance to rock out with media innovators and meet a few of my long-time heroes.

I’m glad there’s a full year until the next conference, but I hope I get to convince all of these folks to come hang out at MIT before then.

I was recently interviewed by blogger Jillian C. York, one of those handful of people with whom I have an oddly enjoyable entirely Twitter-based relationship. The interview was part of a set she’s doing on people’s use of Tor, a web anonymity tool. (It’s run within a program called Vidalia, like the onion, an apt metaphor for how Tor anonymizes your web surfing by passing your data through layers of other users).

The interview was the first time I’d had a chance to think through my use of Tor and other electronic security tools. It comes down to: while I don’t really have anything to hide; while I’m not a security master; and while I’m not a paranoid, it still feels like an obvious best practice, like locking up your bike. It’s easy, and it’s free, so why not take that extra step? (And sometimes you get props, or suspicion, or both, like when Chris Csikszentmihalyi walked by my laptop and said conspiratorially, “You’re running Vidalia?”)

One thing I mentioned in the interview but largely glossed over was my use of TrueCrypt, a harddrive encryption program.

TrueCrypt is freaking awesome. It would take thousands of years to decrypt your data if someone ever got a hold of it. Except there’s a weak link: you have to remember your password. There’s absolutely no password-recovery option. When I went out sick in ’07 with the memory problems, the person Tufts brought in to cover my work didn’t know the password. And neither did I, anymore. I had to go into the office a couple weeks after my surgery, and luckily, amazingly, my fingers had enough muscle memory that they typed out the password on the first try. (But I uninstalled TrueCrypt on both my computers after that. I wrote to Bruce Schneier sometime afterward and asked him what you’re supposed to do about a TrueCrypt password if you have a crappy memory. His three-word reply: “Write it down.”)

Electronic security tools today are dead-simple to use, free, and open source (therefore verifiably safe). They don’t get a lot of attention, but each one of them—Vidalia, TrueCrypt, or a password-organizer like KeePassX—are all worth the 5 minutes to set up.

When I interviewed last summer, both bosses warned me that the biggest challenge about working at MIT is finding time to do all the cool things you want to do and not getting grumpy that you’re missing out sometimes. Case in point: I’ll be at a doctor’s appointment this Friday when I really want to meet the creators of Spongebob Squarepants:

PRODUCING ANIMATION:
Wiesner Room, 10:00am, Friday 1/30

A short lecture and discussion with the producers of The SpongeBob Squarepants Movie and Nickelodeon’s Barnyard Movie. The lecture will be focus on current creative and production practices in Hollywood as well as the role of the producer as it relates to all aspects of digital media production.

Please join Aaron Parry of Main Street Pictures and his associates for this informal inside look at Hollywood animation production.

Not fair! That’s why I schedule appointments for the morning!

A student and the event planner where I work have put together a Mystery Science Theater 3000 retrospective at MIT next Saturday, featuring creators Joel Hodgson and Trace Beaulieu.

Superfriend Patrick and I used to watch MST3K a little obsessively and to this day quote lines from awful movies like “Manos, the Hands of Fate” to each other. So I’m a wee bit excited.

But I’m also scared, because Patrick and I once tried to film our own episode, with his family’s camcorder set up in front of their downstairs television—our only problem was that we were 13 or 14 and had no idea what old movies at the video store were actually bad enough to make fun of. We searched and searched the drama and classics aisle. Then we finally we saw it! Some stupid movie where two characters spend the entire film stuck together on a jalopy of a boat making its way down the Ulanga river. A missionary and a drunk boat captain. Something about fighting Germans.

But we couldn’t pull it off. As hard as we tried, we just stunk at making fun of movies.

Then we got to school on Monday. We told our better-informed friend Jon how we tried and failed. We told him we tried to use MST3K’s humor on some movie called “The African Queen”.

“‘The African Queen‘ ?” Jon asked. “You realize that’s pretty much a classic? Bogart? Hepburn? Like, four or five Oscar nominations?”

So, yeah, I haven’t watched that damn movie to this day, 14 years later. And Patrick and I didn’t try do replicate MST3K again.

But I’m definitely going next Saturday to see Hodgson and Beaulieu!

One of the great things about my work at MIT is the preposterous level of encouragement the people there give each other. Example: even though I’m not a researcher, I get encouraged to post occasionally to the Center for Future Civic Media’s blog because I have a media background and am (nearly) equal in nerdiness to my formal researcher colleagues.

Since I’m in charge of making sure people post to our blog—which can be tough around Christmas—I’ll keep interviews in the hopper for use when posting is slow. Not only is that typical prudent editorial management, but it’s a really great way to approach people outside MIT that I admire.

Here’s a preview. Going up on the site sometime this week is an email interview I did with Michelle Springer, Project Manager for Digital Initiatives at the Library of Congress. Michelle was in charge of managing the Library of Congress’s partnership with Flickr. I asked Michelle to pick some favorite photos from the LoC’s Flickr photostream and to describe how they speak to what Flickr can do for the relationship between the public and a government institution:

The photo http://www.flickr.com/photos/library_of_congress/2178249475/ is a terrific example of the personal history and memories that these photos can evoke. The original caption was “Street in industrial town in Massachusetts.” Flickr members quickly identified the location, and the Library changed the title to Sylvia Sweets Tea Room, corner of School and Main streets, Brockton, Mass., both in the Flickr version and in the Prints and Photographs Online catalog. The Library also added a note to its own online catalog record for this picture (http://hdl.loc.gov/loc.pnp/fsac.1a33856) so that people are pointed to the constantly growing rich discussions out in Flickr.

The rest of the interview is great, so be sure to bookmark civic.mit.edu.

Update: the interview is now posted.