Fishhook International, a Christian non-profit that we have been working with for the past several months, held an event last Thursday at ArtsPlace in Lexington, Kentucky. Ghuna Kumar and Richard Samuel, the organization’s two primary partners, both came all the way from India for the conference. There was light fare and conversation followed by a question and answer session with Ghuna and Richard.

The event also served as a website release party for fishhook.org. We unveiled the website in front of the audience and treated them a live demonstration.

Updates from the Field

A primary goal of the website is to encourage communication between the organization’s Indian partners and their American constituents. Updates from the field are an integral part of the website: partners in India have the ability to post updates about their specific ministries, and the website displays those updates on the relevant pages.

We are continuing to work with Fishhook to develop an in-depth donation system that will enable constituents to sponsor and directly correspond with the hundreds of involved personnel in India.

Fishhook’s History

Fishhook International was started by Ford Philpot in 1955. His son Tim Philpot ran the organization for a period, and Will and Kim Turkington are now at its helm and are helping to revitalizing the organization’s vision and purpose. Our good friend, Kyle Schroeder, designed Fishhook’s stunning new identity.

Paradigm Reborn focuses on websites. Because of this, our portfolio only features web work. But there is the occasional identity or print piece that we design, send off to the client, and then add to the archives, without anyone getting to see it.

This is the remedy to that. Below are a few of the non-web pieces we’ve worked on over the past month or two.

Identity Design, Living Ancestry Media

Identity Design, Zoe Cafe English School

Identity Design, Pursuing Heart Marriage Researchers

8.5″ x 5.5″ Mailer, Springville United Methodist Church

Poster, Kentucky Christian University

Poster, Kentucky Christian University

When I upgraded from Firefox 2 to Firefox 3, Google’s website looked horrible. The spacing between letters was completely jumbled—some letters were crammed in much too close to one another, others had huge gaps between them.

I tried everything from running Firefox in safe mode to deleting every preference file and reinstalling the application, all to no avail. After an entire afternoon of frustration, I finally nailed down the problem: Arial.

Before & after

An outdated font file

Google uses the font Arial on its search results page. By manipulating Google’s CSS with FireBug, I realized that I could correct the spacing issue by specifying any font other than Arial.

It turns out that I had an old version of Arial installed on my computer (perhaps as a result of Darwine).

The solution

To solve the problem once and for all, I simply deleted the old Arial font file. To do this, open the application Font Book. Be sure the “All Fonts” collection is selected. Find Arial in the second column, right click on it, and select “Reveal in Finder.” Font Book will open a new Finder window with the Arial font file selected. Drag the file to the trash.

Because Arial comes pre-installed with OS X, there is a already a correct version of the font located at Macintosh HD > Library > Fonts. If the operating system cannot find a font file in your user account (the one you just deleted), it will then use the font located in your root library.

Why this problem occurs in Firefox 3 and not in Firefox 2 or in Safari I have no idea. But by deleting the bad Arial font file from my home folder, FireFox 3 was then able to access the correct Arial font that shipped with OS X. Problem solved!

As designers, having a proper understanding of how colors relate to one another has a tremendous impact on our work. Here is a quick history of how our predecessors thought about color, and how we should think about it today.

Newtonian Color Wheel

Isaac Newton is credited with the development of the first color wheel in 1666. The color wheel pictured below, circulated in Europe in the late 17th century by an author known as C.B., is based on Newton’s beliefs about color.

It divides the spectrum into 7 pure colors, arranged according to wavelength, with complementary colors arranged opposite one another. The text accompanying this chart indicated to painters that colors adjacent to one another on the wheel were not visually harmonious. They recognized that the opposing complements created the best color combinations. This understanding of complementary colors is the basis of modern color schemes.

While this model provides a good foundation, it only accounts for pure colors, which is just one aspect of a color system.

Harris’s Shaded Color Wheel

In the late 18th century, Moses Harris elaborated on the Newtonian color wheel by charting not only pure colors, but the various shades of those colors as well. If we consider the Newtonian wheel to be a one-dimensional representation of color, then Harris’s wheel introduces a second dimension.

Harris’s color wheel is obviously much more comprehensive than its Newtonian counterpart. However, Harris’s shortfall was a lack of understanding about luminosity, and its distinctness from saturation. As a result, there were certain colors missing from Harris’s catalog.

Runge’s Color Sphere

A breakthrough occurred in 1810 when Philipp Runge portrayed color not as a one-dimensional or two-dimensional color wheel, but as a three-dimensional sphere. Runge was the first to organize colors according to hue, saturation, and value. Unlike Harris, he recognized that luminosity and saturation were unique quantities, and must be plotted on separate axes.

The HSV Cone

Runge’s system of hue, saturation, and value is how you and I should think about color today. The HSV model was formalized by Alvy Ray Smith in 1978 while creating SuperPaint for Xerox, one of the earliest computer graphics applications. While computer screens actually function by mixing red, green, and blue light, RGB is a technical system rather than an artistic model.

Hue, saturation, and value is a more practical model than RGB because it reflects how we typically talk about color. We often use terms like “darker,” “lighter,” and “shades,” which refer to the value component of the HSV model. We talk about a color being “rich” or “washed out,” the equivalent to saturation. And we talk about various colors such as orange, purple, or green, which is hue.

The most descriptive visualization of the HSV model is actually a cone rather than a sphere, as pictured here.

In Photoshop’s color picker, there are individual sliders for for each of these three quantities. Hue is represented in degrees, ranging from 0 to 360, while both saturation and value (called “brightness” in Photoshop), are percentages ranging from 0 to 100.

The Value of Enlightenment

I have found that visualizing color as a cone-shaped model comprised of hue, saturation, and value has helped me make better color decisions in my work. It provides a framework, and prevents me from being overwhelmed by Photoshop’s seemingly unlimited sea of colors. I hope that it is helpful to you as well!

Tired of that plain text e-mail signature that I’ve been using for years, I recently endeavored to create something a bit more professional and refined for my e-mails.

Apple Mail allows you to control the font, color, and even insert images (which are included as attachments) into a signature. But it doesn’t give you direct control of the HTML and CSS, nor does it provide a solution for including images in your e-mail without them being attachments.

These limitations meant that I first had to design the HTML and CSS of my new signature outside of Mail, and then save that HTML file as a Mail signature. Here’s how it’s done.

Designing the HTML/CSS

From my experience designing HTML e-mail templates for FireFly Transmit, our e-mail campaign application, I was already familiar with the obstacles of designing HTML e-mails. Since there are literally dozens of different e-mail clients out there, you have to design for the lowest common denominator to ensure that your e-mail looks decent in each (see the E-mail Standards Project). Here are some of the basics to keep in mind as you design your signature:

• Use tables for basic layout. The CSS float property is not supported in Gmail or Outlook, making CSS layouts impractical.
• Use inline CSS. The style tag is not supported in Gmail, and support for CSS selectors is spotty.
• Only use basic CSS properties. E-mail clients tend to be very picky about which CSS properties they support. Campaign Monitor has a great summary of CSS support in e-mail to use for reference.
• Use absolute URLs. Obviously, relative paths won’t work for an e-mail signature. All of your links should be absolute.
• Link to images. Personally, I dislike it when someone sends an e-mail to me with an attachment that is just their signature image or background file (it makes scanning for other e-mails with legitimate attachments more difficult). Because of this, I recommend linking to your images by placing them on a web server rather than including them as attachments.
• Exclude HTML, HEAD, and BODY tags. When we get ready to save your HTML signature into Mail, make sure that only the relevant HTML is included in your document.

I created my signature with a two-column table—logo in the left cell and text in the right cell. I placed each line of text inside its own DIV so that I could use inline CSS to format each line. I ran into a problem with the spacing between the phone number and company name; padding didn’t work correctly in Outlook 2007, and margin didn’t work in Windows Live. I ended up inserting an additional DIV between the two and giving it a fixed height, which solved the spacing problem in all e-mail clients. You can view my HTML (feel free to use it as a starting point for your own signature).

Saving the Signature into Mail

Once you have created the HTML for your e-mail signature, the next step is to get the signature into Mail. (A thanks to Melvin Rivera and Mez Hopking for introducing me to this technique.) It’s actually pretty simple:

1. In Mail, open Preferences and click on the Signatures icon.
2. Create a new signature by clicking on the plus icon (you can just leave the signature blank for now).
3. Quit Mail.
4. In Safari, open the HTML file that you created.
5. In Safari, go to File > Save As. Then, navigate to Your Home Folder > Library > Mail > Signatures. We want to overwrite the signature that you just created in Mail. Click on the existing signature file, make sure that the format is set to “Web Archive,” and hit Save. (If there are multiple files in this folder, switch the save dialog to the list view. The signature that you just added in Mail should be the file that was last modified just a few minutes ago.)
6. Re-open Mail. Voila!

Testing

Don’t forget to thoroughly test your new signature across multiple e-mail platforms. If you don’t have access to a particular e-mail platform, take a look at Litmus, which can generate screenshots of how your e-mail is rendered in many e-mail clients.

Also, since there are still some people—and quite a few handheld devices—that do not read HTML e-mails, it would be a good idea to test the plain text version of your signature. By default, Mail sends every e-mail as a multipart message, with both an HTML version and a plain text version. In Mail, select an e-mail that has your signature. Then, press Command + Option + U to view the source of the e-mail. You will see many lines of header information, the plain text version of the e-mail, followed by the code view of the HTML version of the e-mail. My signature turned out nicely in plain text.

Wrapping Up

If you decide to create your own HTML e-mail signature—or already have one—we would love to see it! Please shoot me an e-mail and show it off! Also, let me know if you would allow us to display it in an “e-mail signature inspiration” gallery that we are considering doing as a future post.

Video on the web has been catapulted into popularity in the last few years. YouTube gave a kick in the pants to web developers, video producers, and everybody else in the marketing industry, showing us that the public is ready for much more than the text and graphics of yesterday’s web.

In this article, I hope to provide some valuable information to both web developers and video publishers. I’ll cover the rapid evolution from old RealMedia to today’s Flash-based players, as well as some of the most recent updates to the codecs available in Flash.

A Brief History

In the beginning, video couldn’t even be viewed in a web browser, it had to be played in a separate player. Beginning with RealMedia, and moving on to Apple Quicktime and Windows Media, video began to make a postage-stamp-sized dent in the web.

Soon, browsers began to allow video players to embed themselves in web pages. Users still needed to have special software installed on their computers. Microsoft and Apple gained ground over RealMedia by including their own video playback software in their operating systems.

Macromedia’s (now Adobe’s) Flash software has been around for as long as the Big Three video players (RealMedia, Windows Media, Apple Quicktime), however it wasn’t until 2003 that Flash really became a player in the video scene. Previously in the realm of animation and games, Flash 8 included a much improved video codec (On2 VP6) that put its video support in the running with the Big Three.

Today’s Scene

Adobe Flash is now the undisputed winner in web video playback. YouTube, MySpace and Facebook—three of the top five sites on the web—use Flash for all of their video content. The Big Three players still exist in various levels of popularity, but they are dying fast, and RealMedia is leading the way.

Why Flash?

So everybody’s using Flash, and that’s a great thing. It’s good for end users and it’s good for video publishers. From an end user’s perspective, it rarely requires installation. Adobe claims 99% saturation for their Flash player, with 96% using the latest version 9.

From a publisher’s standpoint, Flash video allows for a customized playback interface, as well as the ability to insert advertisements into a stream or provide a visual interface to additional video. Flash’s universal saturation is just as important for publishers, who no longer need to provide multiple versions of the same content.

What About Encoding?

Okay, Flash is the best playback mechanism, but is it easy to prepare and encode video for it? Short answer: it’s easy and it’s about to become a whole lot easier.

Currently, Flash videos are stored in the proprietary FLV format. FLV is the container used to carry the video and audio streams. The streams themselves can be in a few different formats. Older versions of Flash used the Sorenson Spark codec, but the only codec that really provided decent quality at a decent size was the On2 VP6 codec, released in Flash 8.

The problem with the FLV format is its proprietary nature. To encode a video in this format, you need to have software explicitly licensed from On2 or Macromedia. If you have Macromedia Flash 8 Professional or newer, you have the ability to export FLV files from any Quicktime-based application, including Final Cut Pro. Unfortunately, many editing suites only contain video editing software, requiring a separate station for web encoding.

But Wait, There’s More

In December, 2007, Adobe released a highly-anticipated update to Flash Player 9, which includes support for H.264 video playback. H.264 is the one of the latest video codecs, featuring very high quality video at lower bitrates. Part of the MPEG-4 specification, H.264 has already been integrated into many video editing systems.

Even better, the Flash 9 update supports non-FLV video files. This means that video in standard containers (e.g. MPEG-4’s MP4 and Quicktime’s MOV) will play in a Flash player. With no additional software, you can export a file for a Flash player directly from your video editing system (including Apple’s Final Cut Pro and Avid Xpress Pro).

This will effectively eliminate the middleman encoding step present with every other web video technology. Even better, these H.264 files are the preferred format for many mobile devices, meaning that the exact same file you provide in an embedded player can be provided as an iPod and PSP-compatible download.

Wrapping Up

So we’ve talked about how the latest release of the Flash player supports the excellent H.264 codec and it doesn’t require FLV files from a proprietary encoder. Unfortunately, even though 98% of the Internet has Flash 9 installed, it will take a few months for all of those users to upgrade to the new H.264-ready version (version 9,0,115,0). For most users, this will happen transparently or through a small popup.

YouTube has already made a significant investment in H.264, and you can be certain that if they require visitors to use the new Flash player, the entire Internet will upgrade overnight.

In the meantime, as a forward-looking video publisher, plan to be encoding your web-ready videos in H.264 and try not to look back at the ancient landscape of video on the web. It’s been a long, convoluted journey, but with these most recent changes, we’ve finally reached a sustainable system. We no longer need to worry about codecs installed on viewer’s machines, video producers no longer need to be streaming experts, and publishing video content can be as easy as publishing written content.

Stay tuned for more information on how FireFly, our content management system, is making that happen.

For More Information

• Adobe Labs: About H.264
• Adobe: Flash Player Market Share
• Kaourantin: The blog of an Adobe Flash engineer

For a small web design company like us, words such as “collaboration” and “easy to use,” get our attention. That’s why web-based productivity tools tend to meet our needs better than their desktop counterparts. In particular, there are three web-based applications that we have integrated into our workflow with great success.

Basecamp project management

Least surprisingly of all, we use Basecamp—the project management application from 37signals. For us, the flow usually works something like this.

1. We get a new project, so we add it to basecamp.
2. We setup milestones for each deadline within the project.
3. We add the client (usually a team of 4 - 6 people), who then have access.
4. We post messages, usually with planning documents or design mockups that need to be discussed.
5. The client’s team then logs-on individually and posts comments.

The first three tasks deal with setup. For most of the duration of the project, posting messages with attached files and then receiving comments are the bulk of the process.

Using Basecamp has increased our credibility, made collaboration easier, and helped projects stay on track. It’s the web-based app that we’ve been using the longest, and we heartily recommend it.

Blinksale invoicing

For every project there must be a corresponding invoice. That’s where Blinksale steps in. Invoicing usually goes something like this:

1. We create a new invoice by selecting a client, entering line-item information, and setting a due date.
2. A branded invoice is then e-mailed to the client (the template can be customized with CSS).
3. Blinksale keeps track of due dates and indicates when an invoice is past due.
4. When we get a check in the mail, we report it to Blinksale and the corresponding invoice gets marked as paid.

While many of our invoices are for one-time projects, we also bill clients yearly for hosting subscriptions. Before Blinksale, this was a real hassle to keep up with. Now, we use Blinksale’s recurring invoices to keep track of and automatically bill our hosting clients.

The main caveat with Blinksale is that invoices are intended to be sent as e-mail. For some, this may come across as less professional than snail-mail invoicing. Another limitation is that when a client receives the e-mail invoice, he or she must click on a special link to send it to someone else, since using built-in forwarding breaks the HTML design. To combat this, Blinksale now allows its higher-paying customers to send invoices as PDF attachments.

Those issues notwithstanding, we still really like Blinksale’s interface. We tried out other invoicing apps, such as FreshBooks, and found that Blinksale definitely came out on top.

Harvest time tracking

While we use Basecamp and Blinksale very affectionately, our favorite tool of all is the time-tracking app Harvest. These are the basic elements:

• Tasks: Harvest allows you to create core tasks. For us, graphic design, programming, and CSS/HTML design are some of the more common ones.
• Projects: Whenever a new project comes in, we add it to Harvest and choose the tasks that will make up the project.
• People: Each person has a login. Harvest categorizes people as either employees or contractors.

Most of our time in Harvest is spent actually logging our individual timesheets. I choose a project, choose a task, and then Harvest starts a timer for that activity. The timers run at the server level, so I can close my browser and restart my computer; when I log back on to Harvest, the timer will still be running.

Harvest does a great job of reporting. We can easily track how much time we each spend on a given project or task. Harvest indicates the percentage of time spent on billable verses non-billable tasks, compares estimated time with actual time spent, and calculates costs based on hourly rates. You can also export data to Excel, which I recently did to create some end-of-year reports and graphs.

Being able to thoroughly track our time has given us deeper insight into our workflow, helping us use our time more wisely and bid more accurately on projects. Harvest has been the ideal time-tracking tool.

A better workflow

For us, these three web-based applications have enhanced our workflow by increasing collaboration, making common tasks easier to perform, and even transforming the most mundane of chores into… yes, fun.

Over the last few months we’ve been at work tweaking our identity and relaunching our website. The most central visual elements in our new look are the green flourishes that emanate from every page of the website. I have taken those same figures and created a full desktop wallpaper from them for your viewing pleasure.

The primary shape that is repeated in the design is actually lifted from the FireFly logo, our content management suite of applications. We thought this was a subtle way to help unify our brand image.

I don’t know about you, but I'm not a very big fan of Leopard's translucent menu bar. So, what I've done is added a row of solid color that is the exact height of the menu bar in OS X. This way, you won't have a green aurora shining through the menu bar.

I’ve tried to create a version for all the screen resolutions of the current Macs. If your computer isn’t listed, or if you’re using a PC, the last version is probably your best bet.

• 24" iMac (1920x1200)
• 20" iMac or 17" MacBook Pro (1680x1050)
• 15.4" MacBook Pro (1440x900)
• MacBook (1280x800)
• 12" PowerBook/iBook (1024x768)
• Everyone else (1920x1200, without top bar)