Monthly Archives: September 2006

The secret to making a “contact us” form that gets used.

A case study

One of the most interesting projects I’ve been involved with was developing and managing a site for an online automotive accessories retailer. At it’s peak, the site was serving over 20,000 sessions a month, and processing over $1M/yr in sales on the website alone. It was the first large scale projects that I had designed entirely from scratch, using a combination of MS SQL Server and classic ASP.

A favorite feature of the project was custom-written metrics package that intergrated with every piece of the puzzle. Using this system, I tracked everything. You name the metric–it was logged, sifted, mined, aggregated, plotted, and reported. Other than determining conversion ratios from various referers, the most frequent use of the data was a near constant tweaking of the site’s UI, especially the feedback forms. And with thousands of people using the forms, I was able to analyze quite a bit of data.


Designing the proper feedback form is a balance between collecting enough information from the user, yet making it easier than applying for a job at the CIA. The biggest mistake made by developers is believing “the more information, the better. Period.” If you’re using a form to collect bug reports, then that’s probably a good philosophy. However, if you’re trying to turn the visitor into a sales lead, that misbelief will hurt you. When selling something to a person, you need to remove any obstacle, no matter how small, between the person and the sale. Being a computer geek and not a sales weasel professional, I had to learn this in a roundabout manner.

As an automotive accessories retailer, of course one of the first questions on our feedback form was make/model/year of the persons’ car. We’d also ask for their ZIP code in case we needed to quote a shipping rate… and a few radio buttons, asking which department they wished to contact… plus, a checkbox or two asking whether they wanted to be on the mailing list. We had all the bases covered, believing that the more information we had upfront, the better we could serve the customer. However, the problem was that less than 15% of people who viewed the contact form ever actually completed it. I double-checked the form validation routines, making sure that some odd error wasn’t causing it to bomb. I also rechecked the site on various platforms/browsers and monitored the database for connection problems. Nada. Then I decided to experiment with the form itself.

The initial change was removing the ZIP code box. The completion rate went up 4%. At first that seemed odd because it only takes a second or two to key in a ZIP code. In fact, the average completion time (page request to postback delta) was statistically insignifcant. I then removed the phone number input box. Completion jumped almost another 7%, even though it was clearly labeled an optional field. Eventually I whittled the feedback form down to just three fields: “Name” (merging the “First Name” and “Last Name” fields), “Email Address”, and a “How Can We Help You?” textarea. Now more than 40% of the people who loaded the page were completing the form–nearly tripling the number of people asking for sales assistance.

Actions speaking louder than words

Even more interesting was the fact that users were saving an average of just six seconds with the shorter form. Inevitably, it would take more than those six seconds to ask the customer their ZIP code and car model in a follow-up email or phone call. It also meant that we now had to manually route the email to the proper person. However, with a significantly higher “first contact” rate, sales also increased. Speaking through statistics, our customers were saying they’d rather tell us the details after they had our ear. In retrospect, that seems a bit obvious. Like a brick and mortar store, the majority of our customers would go through the checkout process unassisted. However, on occasion, someone needed a bit more help. The verbose feedback form was the equivalent of requiring that a shopper fill-out a comment card before they could speak to the sales staff. How often would you ask for help in a store like that?

Feedback Form Tips:

  • Require either an email address or a phone number, but never both.
  • Log validation errors and use them to improve usability of the form.
  • Besides a “thanks for your feedback” confirmation page, also send the user a confirmation email containing your company’s full contact information, in case the person desires a more immediate response.

Using Apache’s mod_speling to catch unneded 404 erorrs caused by mispelligns

(This article is Part 2 in a series about Apache’s loadable modules. The previous topic was mod_ext_filter).

As former Microsoft-ite who made the leap to OSS, one of the things that took a little getting used to with Apache are that filenames are case-sensitive. While that’s long since been hammered into my soul, a great many other people browsing the web aren’t aware that some webservers are case-senstive, while others are not. Sometimes I’ll see “” in my access logs when what the person really wanted is “”. I could easily catch these simple typos with a mod_rewrite rule, but what if the user entered “” or “”? Trying to plan for the ways a URL could be miscontrued would be make for a lot of ugly mod_rewrite rules. A better choice is to load Apache’s mod_speling module.

Mod_speling is very easy to implement. And what’s more, unlike mod_ext_filter, it can be used from within an .htaccess file–shared hosting users rejoice! The module is normally loaded by default (though spell-checking is disabled), but you might want to double-check Apache’s http.conf:

LoadModule speling_module modules/

Enabling mod_speling is as easy as:

<IfModule mod_speling.c>
        CheckSpelling on

A couple of points to remember:

  • mod_speling will only catch and correct up to one URL misspelling at a time. For true fuzzy matching you’ll have to use a more advanced solution.
  • If Apache finds several likely matching URLs, the user will be presented with a list to pick from.
  • Renaming files and not updating links, relying upon mod_speling to automagically fix them, isn’t a great idea. The module does a directory scan each time it intercepts a 404. If you have a lot misspelled files and a lot of pageviews, you will experience a noticable performance degradation.

For more information, check out the official Apache docs.


Picking the perfect font for writing code.

Programmers use a lot of tools throughout the day. Some of them are pretty obvious: a fast PC, wide monitor (or three), a robust IDE, and good coffee. Other items tend to get overlooked a bit more often: a quality keyboard, top-notch chair, and natural lighting. However, the most underappreciated tool of all is the proper font.

Many designers know that understanding typography is an important element in enhancing usability. Using the proper typeface increases both reading speed and reduces fatique. [1] (PDF) So, why do so many developers just use the default system fonts? Writing a résumé in Word is certainly a different data entry task than matching up curly brackets and double-checking for semicolons for 8+ hours at a time. Different task, different tool. Unhappy with Lucida Sans’ similiar looking 0′s and O’s and Courier’s barely-visible punctuation, I decided to hunt down the perfect font for writing code.

First, my “must haves”:

  • It must be monospaced and legible at smaller-than-normal font sizes.
  • Must be slightly more compressed than most monospaced fonts, which tend to be unusually wide.
  • Zeros must be easily descernable from the letter “O”. Ditto for the digit “1″ and lowercase “L”‘s.
  • Punctuation marks must have some weight to them. I hate squinting at my monitor trying to figure out if a character is a comma or a period.
  • Single and double quotation marks must be surrounded by some white-space so I can tell them apart when using nested quotes.

The “would be nice” list:

  • Preferably free (as in beer), bonus points if it’s free (as in libre).
  • I’m primarily a Windows guy on the desktop, but it would be nice if the font is portable in case that ever changes–especially if I have to pay for it.
  • A good, extended character-set for those rare cases in which I’m editing/reading source written by someone in a foreign language. (Or when I use words like résumé)

Font Finding Fun

I spent almost a full day combing the web, looking for fonts that matched my criteria. I discovered that there are actually quite a few other programmers out there who have sought out a better font (see the links at the bottom of this post). In fact, there are even fonts designed solely with the coder in mind. After trying about a half a dozen of these, I settled on Bitstream Vera Sans Mono.

Bitstream Vera Sans Mono 8pt

Bitstream Vera Sans Mono 8pt

Bitstream Vera Sans Mono 6pt

Bitstream Vera Sans Mono 6pt

I found that Bitstream Vera Sans Mono met all of my mandatory requirements, and all but one optional criterion. The font has the standard Latin diacritics, but is missing support for Cyrillic, Arabic and other non-Western characters. But since it’s free (in both sense of the word), I can easily overlook it. The font is completely usable at 8pt, and still legible even at 6pt. Quotation marks are nicely offset, and zeros have the requsite dot in the center.

A close second was ProFont, which seems to have it’s own fan club. But after a trial run I found it a bit too lightweight for my tastes.

While my coding productivity hasn’t drastically increased since using Bitstream Vera Sans Mono, I have noticed that I squint less and make fewer mistakes when working with nested quotes. My code also just plain seems easier to read. Though I’m sure that actually adding comments would improve readability even moreso. ;-)

Other resources