As a follow up to my previous post about typography, I’d like to share a fun game called “Cheese or Font?”

The concept is pretty simple: the site presents you with a word and you have to decide if it’s a cheese or a font. Pretty brilliant and hilarious, if you ask me.

See the less PC, but just as fun(ny): Steakhouse or Gay Bar?

One of my favorite topics is typography and even though there’s a somewhat limited set of options in CSS, typography can still vary tremendously using pure CSS syntax.

Smashing Magazine conducted a detailed survey of 50 popular websites to see answer questions like Serif or sans-serif? Large or small font? Light or dark background? and more.

Though the findings aren’t scientific, the study shows a clear set of common practices and guidelines for setting type in Web design. Granted, these points should serve only as rough guidelines (not hard and fast rules):

1. Either serif or sans-serif fonts are fine for body copy and headings, but sans-serif fonts are still more popular for both.
2. Common choices for headlines are Georgia, Arial and Helvetica.
3. Common choices for body copy are Georgia, Arial, Verdana and Lucida Grande.
4. The most popular font size for headings is a range between 18 and 29 pixels.
5. The most popular font size for body copy is a range between 12 and 14 pixels.
6. Header font size ÷ Body copy font size = 1.96.
7. Line height (pixels) ÷ body copy font size (pixels) = 1.48.
8. Line length (pixels) ÷ line height (pixels) = 27.8.
9. Space between paragraphs (pixels) ÷ line height (pixels) = 0.754.
10. The optimal number of characters per line is between 55 and 75, but between 75 and 85 characters per line is more popular,
11. Body text is left-aligned, image replacement is rarely used and links are either underlined or highlighted with bold or color.

Of course, every website is unique, and few people want their sites to look like everyone else’s sites. But it’s always great to keep in mind that following these guidelines could make your website feel more familiar to your readers. (If you are a data and spreadsheet nerd like I am, check out the spreadsheet of the study and export its data for further analysis.)

Over at IXDA, I came upon the following post:

Hello,

Someone I work for has a strange enhancement request which I do not agree with, but this person is the boss. I think in my gut, this is wrong.

Website: a user management system for secure student data. Clients are a little paranoid about passwords and user names getting out.

Behavior: when you select a user and want to reset his or her password, the resulting screen shows the user name, but then blanks out the password which you can only see by printing the page.

Blanking out the password seems silly since you can still see it if you print it out. Do people agree this is poor functionality? If so, is there any evidence to support my feeling that this is a bad idea?

I think the writer is smart to be asking for ways to back up his gut feelings about this particular client request. I would agree that the printing of passwords is not best practice, but I’m curious as to why this specific approach is being requested.

I’ve worked with clients who have made suggestions for solutions which didn’t make a lot of sense to me, but upon a deeper dive of their company culture and/or process, I was able to understand why that particular approach made sense to the client. As a consultant, I’m often brought in to solve or address a problem that the client can’t address completely on their own.

So while an outsider’s point of view can be valuable, it’s also important for consultants to listen carefully to requests and understand the underlying reasons for some of those requests. It’s pretty easy to walk into a situation and cite “best practices are xyz,” but sometimes best practices do not make sense for a particular organization. In fact, sometimes the “crazy” approach is the right one, for the right situation and the right company.

But then again, sometimes “crazy” really is just “crazy!”

I love lists. I especially love “Top 10″ lists because anything with more items than that are too hard for me to remember. I think anyone who has worked on a website project can relate to some part of this: 10 Harsh Truths About Corporate Websites from Smashing Magazine.

Here’s the list, but check the article itself for detailed descriptions of these:

1. You Need A Separate Web Division
2. Managing Your Website Is A Full-Time Job
3. Periodic Redesign Is Not Enough
4. Your Website Cannot Appeal To Everyone
5. You Are Wasting Money On Social Networking
6. Your Website Is Not All About You
7. You’re Not Getting Value From Your Web Team
8. Design By Committee Brings Death
9. A CMS Is Not A Silver Bullet
10. You Have Too Much Content

I’ve worked with several clients who have implemented content management systems without realizing the implications of the technology — my role included assisting them with “content scrubbing” before their public go live date.

Consequently, You Have Too Much Content is always on my mind.

Part of the problem with content maintenance on large corporate websites is that there is too much content in the first place. Just because there’s no limit to the amount of text you can put on the web means you should put everything, but most companies do. Most of these websites have “evolved” over years, with more and more content having been added.

Some projects I have worked with have over 10 years of content that’s grown like the Winchester Mystery House; with larger website implementations, few review the content and asked what could be taken away, because content migration and governance is never planned for at any stage of the evolution.

Many website managers fill their website with copy that nobody will read; this happens because of:

• A fear of missing something: by putting everything online, they believe users will be able to find whatever they want. Unfortunately, with so much information available, it is hard to find anything.
• A fear users will not understand: whether from a lack of confidence in their website or in their audience, they feel the need to provide endless instruction to users. Unfortunately, users never read this copy.
• A desperate desire to convince: they are desperate to sell their product or communicate their message, and so they bloat the text with sales copy that actually conveys little valuable information.

Steve Krug, in his book Don’t Make Me Think, encourages website managers to “Get rid of half the words on each page, then get rid of half of what’s left.” This will reduce the noise level on each page and make the useful content more prominent.

In a few cases, the clients have done the right thing: they have taken the opportunity to”clean” their content along with presenting a new look and feel of a new public website. More often, corporate website projects are under such tight deadlines to complete a project from a technical point of view, the very content that needs to be managed is not considered until the last moment.

Many organizations, particularly ones where there might be many content owners, struggle with knowing how much is too much and when it’s appropriate for something to be removed or archived.  Furthermore, some organizations only address these issues when they are doing large revamps or overhauls of their sites and “content freshness” is rarely a high priority item.

There are no hard and fast rules about managing content, but I think what a lot of organizations fail to do is even consider these issues, nor do they lay down any rough guidelines for content owners to work within.

The takeaways:

• The reality is most corporate websites could get away with 20 pages, tops. Just because the page is up there doesn’t mean anyone’s going to visit it.
• When putting up content in the first place, think about how that content will grow in the next five years. Then plan for it.
• When migrating content to a new site, build in time to pare the content — don’t think it’s a straight migration, because the new site will have a completely different information architecture.
• At the very least, establish content standards before the project begins. Remember, it’s a content management system, not a technical management system.