A New Typeface for Road Signs

Last weekend the New York Times Magazine featured an article about the typeface that will eventually grace its presence on all of the highways in the US.

It’s a nice little article about the history of signage for the US Highways. The previous family of typefaces used by the Federal Highway Administration was known as Highway Gothic. The new typeface that’s slated to replace it is Clearview. The picture below shows the old Highway Gothic on the left and Clearview on the right.

Highway Sign in Clearview Type

Clearview was designed by Don Meeker and James Montalbano, with an eye for readability at 70mph. According to their studies, Clearview is quite successful.

In nighttime tests, Clearview showed a 16 percent improvement in recognition over Highway Gothic, meaning drivers traveling at 60 miles per hour would have an extra one to two seconds to make a decision.

That’s a lot of time on a highway.

Kohoi Vinh has posted about the article on Subtraction (one of the best designed blogs around):

Vinh has posted some really nice photos of the print version of the story. It’s a shame I missed the print version. The layout is quite nice. I might just have to go find myself a copy.

Safari for Windows

My first reaction when hearing that Safari was going to be available on Windows was one of pure excitement…and shock. Seriously, who guessed that one?

As far as I’m concerned this is a very good thing for developers. Hopefully, now many of web developers that only design for Windows will at least attempt to make their sites work in Safari. It will also be easier testing sites for me when I’m working on a Windows machine.

Unfortunately, this is Safari 3, and if the WebKit builds are any indication of the improvements, most of the annoying bugs in Safari 2 have been fixed. This means that I’ll still have to continue testing with Safari 2 for some time to come. I read somewhere (can’t remember now) that the Safari 3 beta installer completely overwrites your copy of Safari 2. Damn them! When will companies quit doing this to us web developers/designers? I don’t want to have five computers just to test different browsers.

Despite my excitement about having Safari on Windows, I have no intention of using it as my primary browser. As I’ve said before, a big part of my browser experience is how it fits in with the user experience of the operating system it runs on. I’m not talking about coupling browsers and OS’s (IE), just that a browser should look like it belongs on that system. I’ve never liked using Firefox on a Mac, and now I can definitively say that Safari looks just plain weird in Windows.

Yesterday I was reading various complaints how Safari renders text on Windows. The common complaint seems to be that the text is blurry:

I heard this complaint echoed all over the blogosphere yesterday. My initial reaction was to dismiss most of these people as Windows users used to text that looks like it’s not anti-aliased. As a graphic designer I have to say that I hate the way that browsers on Windows render text (IE7 is much better than the rest). I’ve always preferred the way that text looks on OS X; that’s one of the reasons I prefer it as an operating system.

So last night I tried out Safari 3 for Windows myself. I didn’t have any of the weird installation or crashing problems that many others have noted. Granted, I only took her for a short spin through the tubes. For the most part, I liked what I saw.

Surprisingly (to me), I noted that the text definitely looked a little bit blurry. I suppose after a time I’d get used to it, but I have to say that Safari seems to have gone to the opposite extreme as far as font rendering is concerned. Firefox gives us very pixelated looking text while Safari gives us smooth and blurry. Hmmm.

Overall, I think this is a great win for developers across the board. Hopefully this will increase the awareness that Safari does exist and some people do use it. For the average Windows user, I’d say it’s kind of a non-announcement. People using IE won’t care about Safari, and nobody in their right mind would ditch Firefox for it. Safari just doesn’t offer anything that Firefox doesn’t have for Windows. Also judging from the security exploits that have already been released, it appears as though Apple has something to learn about developing browsers on Windows.

Creating An Archives Page In WordPress

In my most recent blog design I’ve created a single page for all of my post archives. Previously, I had links to my monthly archive pages in the sidebar. After blogging for about 14 months, this list became a little bit unwieldy. My solution was to move the entire archives section out of the sidebar, and into its own page. The archives page is now more prominently linked from the main navigation bar.

Unfortunately, doing all of this in WordPress is not quite as straightforward as one might hope. Now that I have mine all set up, I figured I’d post a walkthrough of how to set up something like my archive index page.

Get A Plugin To Do the Dirty Work

Unless you’re interested in writing the PHP code and MYSQL queries to retrieve all of your archives in an organized fashion, a plugin is the way to go. After a quick Google search, I found the SRG Clean Archives plugin. This plugin is quite nice I’ve found. It’s realatively easy to implement and also (and importantly), it’s also very easy to modify to fit your site design.

The plugin will give you a list of all your post titles, organized by month. There is also the nice feature where the post titles begin with a post date. Check out the clean archives demo page for an example.

Simply install the plugin like any other normal plugin and then activate it.

Set Up the Archive Page In WordPress

The next step is to set up the actual archive page in WordPress. There is a tutorial in the WordPress codex about how to do this called Creating An Archive Index. I’m just going to briefly outline the steps here.


Open your archives.php file. If you’re using a basic template, then this file probably already exists. If you’re using the default Kubric theme, your archives.php file will look like this:

Template Name: Archives

<?php get_header(); ?>

<div id="content" class="widecolumn">

<?php include (TEMPLATEPATH . '/searchform.php'); ?>

<h2>Archives by Month:</h2>
        <?php wp_get_archives('type=monthly'); ?>

<h2>Archives by Subject:</h2>
         <?php wp_list_categories(); ?>


<?php get_footer(); ?>

As always, I would suggest making a backup of this file before changing anything. Now modify the archives.php file to look like this:

Template Name: Archives

<?php get_header(); ?>

<div id="content" class="widecolumn">


<?php get_footer(); ?>

If you’re using your own template (like I am), then you may need to either update or create the archives.php file to make sure it is consistant with your blog design. A good starting place for this is to simply copy your single.php file to your archives.php. Now, delete the entire “loop”.

Note on Page Templates You can create any kind of page template you want. All you need to do is insert the following code at the very top of your PHP file.

Template Name: template-name

Make sure your archives.php file starts with these lines, or else you’ll be banging you head against the monitor trying to figure out while ‘Archives’ isn’t listed as an option in the Page Template dropdown menu. Believe me, I speak from experience.

Create A Page In WordPress

Now have to set up a plain old page in WordPress.

  1. Login to the WordPress Admin area
  2. Go to Manage -> Pages
  3. Click Create a new page
  4. Enter an appropriate title. This will be the title of your archive index page.
  5. Leave the content area blank
  6. In the Page Template box, select Archives.
  7. In the Page Slug box. Type something suitable as this will be the permalink for your archives page (http://www.your-blog-name.com/page-slug/).
  8. Click Save.

Now obviously, you have to create a link to your new archives page. We already set it up, complete with the URL. Yours should be in the form of http://www.your-blog-name.com/page-slug/. Just make a link to it somewhere on your site.

Call the Plugin

As you’ll notice, our fancy Archive Index is empty. In order to get all of our archives in there, we have to use a simple PHP function to call the SRG Clean Archives plugin.

Open your archives.php file again. Find this section of the page:

<div id="content" class="widecolumn">


Now add the following PHP function to call the plugin:

<div id="content" class="widecolumn">
    <?php srg_clean_archives(); ?>

Save the archives.php file and refresh your browser. You should now see a nice list of all of your archives.


As I noted earlier, the SRG Clean Archives plugin is nice because it’s easy to modify if you want to. The Clean Archives website is well documented and the plugin contains a readme file explaining this as well.

The default style for SRG Clean Archives is to output the month and year, surrounded by <strong> tags. You might want something else, like a list or header tags.

To change this, open the srg_clean_archives.php file in your plugins folder and find the following line:

 echo get_archives_link($url, $text, '','<strong>','</strong>');

Modify the strong tags to suit your needs. For example, mine now looks like this:

 echo get_archives_link($url, $text, '','<h2 class="archivemonth">','</h2>');

You can find more information about this on the SRG Clean Archives plugin website.

SRG Clean Archives also provides you with class names so that you can style list however you want in your CSS. I’ve added the following styles to mine:

/* For Archive page */
h2.archivemonth {margin:30px 0 0 0;padding:0;}
    h2.archivemonth a:visited {color:#9db550;}
ul.archivelist {border-bottom:1px #ddd solid;list-style:none;margin:0;padding:0;}
    ul.archivelist li {border-top:1px #ddd solid;}
        ul.archivelist li a {display:block;padding:2px 0 0 20px;}
        ul.archivelist li a:link, ul.archivelist li a:visited, ul.archivelist li a:active {color:#000;}
        ul.archivelist li a:hover {background-color:#eee;color:#000;text-decoration:none;}


Note: I changed SRG’s default class name from ‘postpermonth’ to ‘archivelist’.

That’s All

Well, that’s pretty much it. I hope you guys find this useful. Feedback and corrections are always appreciated.

Update 2/25/09: This method was tested and works on SRG Clean Archives version 2.1. This version is old! Please check out all of the feature upgrades for the plugin from it’s home page. If you still want to proceed with my method, you can download the plugin here:

Mac Users and Cross Platform Apps

About a month ago I blogged about my feelings on Mac browsers in Mac Browsers and Non-Native UI. My basic feeling was that the best browser that’s made for a Mac always wins. Firefox is a great browser, but it’s not made for a Mac.

A recent article on Theocacao has basically reinforced what I said in my previous post. It’s well worth the read.

Stevenson’s main rule of thumb for Mac development:

Mac users will generally favor an app with a better experience over the one with more features.

Make sure to read that twice. He’s absolutely right.

Getting back to the browsers, Stevenson uses Firefox as an example for the above point:

A textbook example of this is Firefox. A great browser, but Safari is far more popular on the Mac because it’s designed for a Mac user. In fact, this runs so deeply that Camino — a Mac-only app which uses the same Gecko engine that Firefox does — enjoys a fairly strong following.

Web 2.0 Inspiration

Looking for inspiration for Web 2.0-ish designs? Here are two posts which list a lot of different designs. One is for CSS style navigation and the other is for those big chunky footers that are in vogue right now.

And also, over at Smashing Magazine is an excellent list of tutorials to make all those pretty (and often superfluous) Web 2.0 style graphics.