In our company, code reviews play an integral part in the development process for making quality software. We opt for a mentor style approach with Wufoo, where a developer works on a segment for a period of time and then passes it up to a more experienced developer for review. We really like this approach because it means more developers become familiar with the foundation of different code level services. More importantly, they act as an additional safeguard against security holes, memory leaks, poor queries and heavy file structures. Unfortunately, these reviews are also very time consuming and in a small team can sometimes be an inconvenience to the reviewer — another developer with their own todo list to accomplish.

Given that all reviews check against the same list of requirements, we’ve found ourselves repeating the same tasks over and over again. We spend a lot of time echoing queries, memory stats and objects to the browser just to see how they are being used in the code. To reduce this repetition, we invested some time creating something we’ve called the PHP Quick Profiler—we call it PQP for short. It’s a small tool (think Firebug for PHP) to provide profiling and debugging related information to developers without needing them to add a lot of programmatic overhead to their code. Now, we only need to toggle one config setting to true and our reviewers have access to an automated tool to help create a faster and more consistent review experience. Since anyone can use it, PQP also gives the initial developer an idea of where their code stands before the review.

We’ve been using PQP for a while now with Wufoo. It’s been so useful that we decided to take some time to package everything, write out some documentation and offer it up for anyone to use.

See it in Action

We’ve created an online example showing a landing page with PQP turned on. The profiler contains a 5 tabbed interface that presents pages for logging messages, measuring execution time, analyzing queries, revealing memory used and showing the files included.

Thanks to Kevin’s help, who did a great job of designing and encapsulating the interface, there’s no need here to add links to external CSS files or Scripts to make it show up right. When included on a page in PHP, PQP automatically inserts the markup, CSS and JavaScript needed to make the interface show up and just work. PQP should work with Internet Explorer 6 and up, Firefox and Safari.

Getting Started

We’ve provided a zip file which contains the entire setup for PQP and some basic instructions for installation.

Download: pqp.zip

Once you’ve downloaded the zip, upload the contents to a PHP enabled web server. Navigating to the root directory in your browser will show the same online example we linked to above. At this point, each tab should work except for the database tab, which requires some additional configuration.

Once you get the example working, the next step would be integration with your own project. It’s important to note that dropping the folder into your own project directory will not work. This is because 5 different aspects of the code are being looked at, and you may handle those situations differently than we do. That said, integration is pretty straightforward, and by following the guidelines for each section below, you should be up and running in no time.

Using It In Your Code

The easiest way to make PQP work in your own code is to include PhpQuickProfiler.php into the page you want to see it on. That alone will enable the console, memory and file logging. Speed and database logging take a bit more work, which we’ll cover later. Now, enabling the default logging is great, but nothing will display to the screen by just including the file. To display to the screen, a bit more knowledge on what’s happening is required.

As code is being executed, details are being logged and analyzed in PQP. Once the code is finished, PQP finishes up also, and displays the output to the screen. The tricky part is knowing when the code is finished, since in an ideal world this tool would work with as little developer input as possible. In this example, we determine that the code has finished by looking at when the parent object runs its destructor. So a timeline would be:

• Landing Page constructor declares an instance of PhpQuickProfiler.
• Landing Page executes all needed code.
• Landing Page destructor tells the PhpQuickProfiler to cleanup and display output.

Of course, this setup would cause PQP to always display, which isn’t ideal for production. To make it more useful, we created a Config flag in our code (debugMode = true) that checks to make sure it is set to true before displaying. Below is a sample class that can perform the steps we just covered:

class ExampleLandingPage {

    private $profiler;
    private $db;

    public function __construct() {
        $this->profiler = new PhpQuickProfiler(PhpQuickProfiler::getMicroTime());
    }

    public function __destruct() {
        if($debugMode == true) $this->profiler->display($this->db);
    }

}

Logging to the Console

Given the code shell above, PQP is configured and ready to be used. We can start referencing the helper functions, starting with logging. The console log is just a step above an echo statement in that it condenses and formats the output using print_r. This is useful for reviewers because it provides a way to view debugging information without blowing up the layout of the page. To output data to the console, just statically call the function:

Console::log($data);

The static function call accepts any data type and is available as long as the PhpQuickProfiler.php class is included. We chose to implement this with a static call so that the class does not have to be instantiated before use. The downside to a static call is that we store the log history in a global php variable. Should you wish to avoid globals, the Console.php class could always hold the log as a member variable given that it is instantiated. But as is, the class just acts as a read and write wrapper around a global PHP variable.

On top of logging variables, the console also has four additional functions.

Console::logError($exception);
Console::logMemory();
Console::logMemory($variable, $name);
Console::logSpeed();

Let’s start with logError(). Logging an error is useful for displaying information related to a PHP exception. In our code, we’ll use a catch block for handling errors so we can silence an exception. We do this because we want that error to be ignored and not affect what the user is doing. An example of this would be logging data that isn’t crucial. If that log fails, the users shouldn’t have to stop what they’re doing. Now, in development, it’s still nice to know those exceptions were thrown, so in the catch block a call to logError() can be made to display the information to the console like so:

try {
    // Execute non critical code
}
catch(Exception $e) {
    Console::logError($e, 'Unable to execute non critical code');
}

Additionally, the console can provide even more value by using some of the helper functions that PHP natively provides. For example, logging debug_backtrace() will print related information about the script at a given point in time. PHP also provides us with magic constants like __LINE__, __FILE__, __FUNCTION__, __METHOD__ and __CLASS__, which allows for printing of script data. Take a look at the screenshot below to see some example usage of this:

Watching Memory Usage

Object oriented PHP is a beautiful thing to behold, but there are definitely a few concerns to keep in mind when it comes to memory usage. These concerns tend to rear their heads when dealing with recursive output (i.e.: exporting to Excel), if there’s a leak in the creation of the objects or if objects aren’t being destroyed properly. All of this can lead to unexpected resource usage and fatal errors that serve to aggravate the end user.

The debugger aids with memory management by displaying the maximum amount of memory used by the script. A simple call to the built in memory_get_peak_usage() is where the data originates. The system setting for memory allowed (through ini_get()) is also shown to see how much wiggle room there is. If an overview isn’t enough, you can drill down into your resource usage with a point in time memory call.

Console::logMemory();
Console::logMemory($variable, $name);

Calling logMemory() in your code without any parameters will output the current amount of memory that PHP is using when the function is called. This is perfect for watching a loop in your script to see if memory is building up during each iteration. Likewise, a variable and a name can be passed in to the function. Doing so will output the memory used by the variable to the console. Knowing that a script is hogging memory is wonderful, and knowing which variable is doing the hogging allows the problem to be fixed. Take a look at the screenshot below to see an example of string concatenation that is slowly eating up memory.

Runaway Includes

Similar to memory getting out of control, included files (especially on large complex projects) can multiply and take over your app before very quickly. Even worse, too many includes don’t throw the hard errors that memory usage does. Instead, the page just slows down and resources get eaten up on every request served. Avoiding this pitfall is pretty easy—just make sure the same file isn’t included multiple times, and catch any excessive includes of unnecessary files.

The PQP files tab shows the total files included with a count call on get_included_files and their total sizes are summed up. The names and sizes of the individual files are output to the console for easy scanning as well. The largest file included is noted on the left, which clearly points out if a large library is being used when it shouldn’t be. For example, on Wufoo we found out that we had a script always including htmLawed, a fairly decent sized file, when it wasn’t needed.

Also, keep in mind, autoloading classes or using require_once will usually alleviate any problems with file includes. That said, it never hurts to be aware of the situation, especially when using plugins, old code, or borrowed code.

Page Execution Time

Emphasis is always placed on database optimization when it comes to performance considerations (rightfully so), but that doesn’t mean PHP execution time should be ignored completely. The standard method for calculating load time is to find the difference between the time when the script starts and then again when the script finishes. This is where the integration of the debugger into your own project becomes tricky. Since the debugger is called on the destruction of the parent page, we know when the script is ending. But since every project is different, the start time can vary. The example code that you can download sets the start time in the construction of the parent object with a call to PQP’s getMicroTime(). This will work in most cases, but if you have a lot of code going on before the parent is constructed, be sure to specifically set the start time when needed.

$this->profiler = new PhpQuickProfiler(PhpQuickProfiler::getMicroTime());

Given the page execution time, the next step would be to find meaning in the information. A quick glance will show if the time falls into an acceptable range. Assuming it doesn’t, how would we go about debugging the problem? Using the query section of the debugger, we can rule out query execution time (explained more in the next section). If queries aren’t the problem, then some portion of the script is. We can find this with the console.

Console::logSpeed();

A call to logSpeed() will tell us how long the script has taken up until that point in time. For example, imagine we have an object factory that constructs complex objects from a database. We also have an object engine that returns the object names from a database. When displaying 100 objects names to the screen, we would use either the factory or the engine. But using the engine would be much faster because we only need the names, and do not need the logic processing of object creation. If the developer did use the factory, logSpeed() would reveal the slowdown in the display loop, which ultimately identifies the problem.

On a similar note, we recently discovered that xCache improves our page execution time by over 60%. This was compared against other benchmarks by having all of our developers run quick tests against the code they were responsible for using PQP.

A Glance at Database Activity

Getting the debugger to report database information is the hardest part of integration with your own project. This step will only work if your database interaction is abstracted in some way. We talked about a simple database class awhile back, and have also released an example with the zip download (MySqlDatabase.php — you can follow the code in there to see a full implementation). The reason a class is so important is because information about each query must be stored as it happens, and a class allows the queries to each go through the same analysis without additional work by the programmer.

As a query is called, the database wrapper class stores the query and logs the time. The simplified code looks like this:

function query($sql) {
    $start = $this->getTime();
    $rs = mysql_query($sql, $this->conn);
    $this->logQuery($sql, $start);
    return $rs;
}

function logQuery($sql, $start) {
    $query = array(
        'sql' => $sql,
        'time' => ($this->getTime() - $start)*1000
    );
    array_push($this->queries, $query);
}

Using that concept, the class will have an array of all query information available to it. Then, the debugger can take that array and print out the information. The information that is currently stored is the query itself, and the time to execute. The time to execute is not exact — it is the microtime until PHP has a handle on the recordset, which will be slower than the query time if there is network latency with the database server. Viewing the queries at a glance is an easy and helpful way to look for queries that would affect more records than intended, that are being duplicated or those that open themselves up to SQL injection.

One of the most useful database features added to the debugger is the ability to EXPLAIN each query run. Each query is run again using the explain statement, and the results are presented below the query. This makes it easy to identify which queries are using their indexes properly.

Wrapping Up

The end goal of this debugging tool is to present a summary of useful information in an automated format. Usually, finding out about certain aspects of the code would require manual work and thought. And then if a problem is encountered, the debugger will hopefully make narrowing down the problem easier through the use of the extended Console functions. With that in mind, this tool is just an aid and is in no way meant to replace the standard, thorough procedures available to developers. The slow query log, PHP error log and full fledged debuggers and profilers are encouraged on top of this high level view to supplement the tools available to developers.

Now, our funding situation is that we took some initial seed money ($18,000) from Y Combinator and then followed that up with a small angel round ($100,000) to get us to launch. That’s all the money we’ve taken and that was all done within the first 4 months of 2006. Since then, we’ve been blessed to have Wufoo do very well out there and we’ve been able to grow our team, product, user base and profits solely off of the service’s revenues. We did not take VC money because 1) we like control and shares and 2) we just weren’t interested in getting big fast, which meant VC money seemed like overkill to us in regards to our plans for growth. So when these calls started coming in, our stance was (and still is) that we’re not interested in seeking additional funding, but we’d be happy to talk because, well, you never know.

Of course, before every one of these phone calls, we would look up the firm’s web site, we would read their history, we would look at their portfolio, we would look up the associate that we’re going to talk to (there’s always a photo and there’s always a bio) and we would even look up some of the companies their firm had invested in. If the associate we’re going to talk to had a Facebook, Twitter or Linkedin page, we would look at that too. We think of it as basic research and it’s just how we do things. It’s how we write the articles on this blog and it’s how we make all of the decisions in our company. We’re like boy scouts. We like being prepared.

Additionally, we think it’s a basic form of courtesy to show someone else a level of concerted interest, if they’re showing interest in us. This way, hopefully, time would not be wasted on posturing and excessive introductions. Unfortunately, it’s become very clear to us after every one of these exchanges (there are no exceptions I’m afraid) that these investors and associates do not do the same. All of the associates we talk to seem to have three goals in mind when they contact us:

1. To put us into a database of companies their firm is aggregating. From what we understand, most VC firms send out an army of these associates to just gather basic research on companies, but for some reason, their flavor of choice for data collection is via a phone call rather than actually using the Internet to scrape most of the mundane stuff that they’re asking us. We’ve actually had conversations where we can hear them typing into a spreadsheet in the background as we talked to them.

2. To regurgitate the firm’s history and mission statement from their web site. We noticed this early on and that’s why we started going over them ahead of time so we could skip it, but apparently this information must always be passed on orally to a potential company regardless of whether the company is able to finish their sentences.

3. To let us know that they were different, that they give more than just money and that we should keep them in mind when we do decide to take on more funding. Needless to say, we find it very odd (if not funny) to hear every firm state how different they were in exactly the same way as everyone else.

Obviously, we are not against gathering research. We are not against unsolicited introductions. And we actually think the intention of the act—to start an earnest conversation or relationship with a company that appears promising is a great idea. We’d love that. But the execution of these exchanges completely baffle us. Every associate asks us the same surface questions that can easily be answered by reading a few short pages on our web site (specifically our FAQ and our About pages—they are definitely not hard to find). In fact, we’ve actually had people call us with promises of expertise and advice that’s never even created an account with Wufoo or know how we made money (that we have a freemium software-as-a-service subscription model).

Now, we understand that the typical relationship regarding a startup and a VC firm is to have the startup pitch to the VC. It is the startup’s job if they want money to convince the VC that they are worthy of investment. We also understand that the associate that’s calling us is making like a million of these calls a day. It’s probably just a job to them. We get that. We do.

However, if it’s the VC firm that initiated an unsolicited conversation and the company indicated ahead of time that it wasn’t interested in more money, and the VC firm insisted on talking anyway…well, then it’s sort of not cool to not do your homework and effectively make the company do the pitch anyway. Then we’re doing your job. Then, when you show the company how not different you are from everyone else following what is apparently the same lead, you’ve accomplished the exact opposite of what you intended: We do not think you’re different. We are not confident in your ability to establish strong relationships with companies. And we will probably not think of you when we need funding later on.

I know. That’s really harsh stuff. In fact, I’m unfortunately notorious for being rough on venture capitalists during meetings when we were based in Silicon Valley. Which is why 1) I’m not allowed to sit across from potential investors during lunch/dinner meetings so they can’t see the reactions on my face and 2) Chris, Ryan and I rotate returning these calls to VC inquiries. And so, thankfully, it’s not just me. We all feel surprised, which means these firms are probably giving the same impression to countless other companies.

What we find surprising is how every single one of these associates miss the opportunity to be a hero—to truly make an impression. Because, honestly, it’s so bad out there, that it would probably take very little to actually impress us even a little bit. All you would have to do is indicate to us that you’ve at least read the marketing materials on our web site (the thing that you want to pump money into) and tried out our service (the thing that’s potentially going to make you more money).

At least then, you’d be in a decent position to have a conversation that has give and take—maybe even provide criticism that we might find valuable. And that would be the event that would have me write down your name. The moment someone tells me, a person that’s been thinking obsessively about how to improve my company 24/7 for the last 3 years, something insightful about my business, product or future that I haven’t thought of before would be awesome. Also, bonus points would probably be given to the investor that calls us with knowledge of any of the number of articles we’ve labored over for this blog.

Anyway, the take away from all this for venture capital firms is that we’re not really complaining. I mean, technically that’s all I’ve been doing, but I also want you to know that we are definitely honored to be in a position to have VCs that want our attention. We know that’s a rare position to be in and we don’t take it lightly. Which is why we’re actually rooting for you. For that hero associate out there to get a hold of us and maybe knock our socks off with a little insight or even just some good ol’ fashioned genuine enthusiasm. For good reasons, we don’t want our time wasted. And we really do want you to accomplish your goals, which is to be remembered. You don’t have to be our biggest fan. We don’t expect that at this point, but we do think that if you’re asking us to consider handing over a percentage of our soul (a soul that we’ve cultivated with our own blood, sweat and tears) in the hopes of capitalizing on our now apparent successful trajectory, then we’d hope that you’ll at least do us the honor of reading our words and learning our craft.

While I’ve highlighted best practices and resources on how to pitch your ideas in the past, I thought I’d take some time to share exactly how we prepare for our demos when we’ve been invited to showcase Wufoo at conferences, events and VC boardrooms. We’ve spent a lot of time refining and practicing our workflow for presentations and after doing this a number of times now, I think we have a method that seems to produce results that we’ve been pretty proud of. While the amount of prep work we do probably isn’t for everyone and might be overkill to some of you, hopefully there will be some tips in here that will help you in your own presentations and demos.

For all the examples in this article, I’ll be referring to the prep materials I generated for a 7 minute demo we were asked to do this past summer at the National Society of Collegiate Scholars Convention in Orlando, FL. Because we (the founders) have demoed Wufoo countless times, we had one of our new hires, Tim Sabat, do the presentation to get some experience under his belt. Because this would be his first time with the material and because we’re obsessed about polish, you’ll notice that we leave very little to chance and improvisation.

Getting Started

If we’re presenting something completely new, we’ll start about a week before the presentation. If it’s something I’ve presented before and I have the slides and prep work already done, then I can probably get away with looking at stuff a day or two before. Either way, I’m probably going to be working and tweaking the slides all the way up until the moment before it’s time to go on stage. Because I wanted to try a new script (Wufoo had a lot of upgrades since the last time we demoed it) and Tim was new to this, I treated this presentation as if I were creating it from scratch.

We like to start every presentation with a rough outline. In fact, I pretty much start every thing I ever write with an outline and it’s one of the most common recommendations I have for people that have trouble with rambling and organization. It seems obvious, but you’d be surprised at the number of people that try to wing these things. Outlines keep us focused and help us make sure we hit the points that we need to cover like who we are, what we do, who uses us and the major features we want to highlight in the app. Here’s the outline I developed for our NSCS demo.

Introduction

- Particletree
- Treehouse
- Wufoo

What is Wufoo?
- online form builder
- help people collect information over web
- Infopath but friendlier

etc.

The Transcript

If the time allotted for the demo is under 15 minutes, which this was, then I basically take that outline and write out a full transcript—a word for word articulation of what would be said during the presentation. Not going to lie, it’s a lot of work to do this, but it’s definitely worth it. During a 6-8 minute demo, there isn’t any time to waste on finding your words. We believe a good short demo is like a good short story—it’s carefully crafted. Even with material that feels like I should be very familiar and intimate with it (like talking about a startup and application I created from the ground up), I feel much more comfortable knowing that if I have a brain fart on stage, there’s a safety net for me to read from. Here’s a copy of the final transcript I made for Tim for our NSCS demo.

The first version of this transcript is written as fast as possible since I know that it’ll go through lots of revisions when we start timing it and whittling it down. After the first draft is done, I’ll do a time check. Basically, I time how long it takes to read the introduction, how long it takes to read the demo and how long it takes to read the closing. I’m careful to make sure I’m reading slowly but clearly (I actually have a problem with speaking too fast when I’m confident), which is probably the most important part of this process. For me, I know I’m reading at the right pace when it starts to feel a little uncomfortable. Timing and reading out loud will let you know where there’s flow problems and also what needs to be cut or made more succinct.

For this presentation we aimed for about 2:45 in the introduction, 2 minutes for the demo and then about 2 minutes for the closing. Now, when we first launched Wufoo, we didn’t have any of the information on traction and usage and so during those presentations, our intro was obviously shorter and our demo time was then extended to show more features. One thing we’ve learned about demoing features is that it’s impossible to show everything. Even if I took the entire 7 minutes, I couldn’t show all the things possible with Wufoo and so it was important for us to hit the highlights and then compromise by just showing screenshots of other major features to wet an audience’s appetite and imagination for more.

After I was happy with what I came up with, I sent a copy off to Tim so he can look over it and let me know what phrasings didn’t sound like him or felt uncomfortable rolling off his tongue. I’ll also have him do a time check since he’ll actually be presenting. When that’s done, I’ll leave him to practice while I work on the slides.

The Slides

I do all of our presentation work in Keynote. We’re all on Macs and so it’s very convenient. And while I do love the way everything looks on it, I’m pretty sure I could be just as effective with the latest version of Powerpoint. Here’s a copy of the slides from the NSCS Demo.

The nice thing about making slides from a transcript is that it’s much more efficient. When I’ve made presentations based on just an outline in the past, I would usually waste a lot of time making a bunch of pretty slides that ended up being cut out of the final presentation after going through a few rehearsals and timings. In regards to actually designing it, there are so many ways to effectively illustrate a presentation. Since we’ve covered this in past articles, I’ll just share some of the things I like to do when I design one:

• As you can see from the slide overview above, I like to use a lot of bright colors, images and screenshots. I prefer to illustrate rather than explain.

• When showing a web site, I’ll cover a screenshot of the site with the url in large text so it’s easy to read even in the back of the room.

• When I purposely want the audience to feel overwhelmed, I’ll show lots of text or images on a single slide. Otherwise, it’s never more than a short sentence, if that.

• Duplicate the first slide. A tip I got from Tim. This way you can leave it up on a screen without my notes showing or the timer starting.

• Try to use humor when possible. Sparingly and tastefully, of course.

• Add any slides at the end that will easily answer some of the most commonly asked questions (this is why pricing page is added after the Thanks! slide).

Additionally, I try to avoid using any transitions or animations in my presentation. I know some of them can be really slick, but in a demo with strict time limits, not only do I fee like I don’t have any time to waste, but I also don’t want the audience distracted by eye candy that makes them wonder about the software powering the presentation over what’s actually being said.

Using Notes

In Keynote (and I’m pretty sure in Powerpoint as well), you can add notes to each slide that will only display on your laptop when showing slides through a secondary display. Honestly, I think this notes feature is one of the most under-appreciated features in presentation applications. Ever since I’ve started using them, I’ve never gotten lost again or wondered why a certain slide was showing in the middle of a presentation. And so after the slides are done, I’ll start to copy and paste the appropriate sections in the transcript into the notes for each slide. Here’s a copy of the slides with the transcript inserted as notes.

One thing that you’ll notice in the slides with notes is that certain sentences or phrases are copied across multiple slides and formatted with odd line breaks. The duplication is done so that if a sentence is illustrated by multiple slides, the rhythm of a sentence won’t be disturbed during the slide changes. Each new paragraph represents when the presenter should proceed to the next slide.

In Keynote, I’m not a fan of the default layout for showing notes. Thankfully, you can change these settings under Preferences -> Presenter Display -> Edit Presenter Layout…

Obviously, you should experiment and find the layout that works best for you, but I like to maximize the amount of notes I can see and so the presenter layouts for my keynotes are set up like this:

Pre-Recorded Screencast

There are a number of studies out there that show that mult-tasking is a myth. Our brains aren’t meant to do it. It should therefore be no surprise that driving your application and talking about it articulately at the same time is a really hard thing to do well—especially, when you’re under pressure to do so in a narrow range of time. During practices, we’d notice that when we tried this, it was never smooth. There would be awkward gaps of silence whenever any thought processing needed to be done to show off a feature and, for some reason, the ability to type always seemed to escape the person when they were talking at the same time. That’s when we made our demos a two man operation.

One person would drive the application and the other person would do a running commentary of what was happening on the screen. This worked out alright, but it also had its issues. For example, there would be this awkward transition where you have to wait to pull out of the program and then open a browser to start the demo part. Because of this, you couldn’t fall back on your notes inside the presentation software, which means you have to effectively completely memorize this part of the sequence along with your driver.

You could bring two laptops, but most displays at conferences aren’t prepared for this setup and you end up with an even more awkward transition that has the potential for a dreaded AV malfunction. Additionally, this also added two additional variables to your presentation: another person and another piece of software. In addition to having to pay for two people to do every demo, you and your driver both have to be in sync and your application just has to work. Even though we would run everything off a development localhost on our laptop so we wouldn’t have to rely on an Internet connection, it always made us nervous. And so after a few presentations run like this, we decided that it would be better to just pre-record the demo as a screencast. Here’s a copy of the movie used in the NSCS demo.

Using a screencast solved the awkward transition problem, allowed us to still utilize notes, eliminate the variables of another person and software and made sure that we would not go over on time for that part of the demo. Keynote makes it very easy to insert movies into presentations. Just drag the movie into a blank slide and it’ll work pretty much like you expect. The only problem I have with it in Keynote is that the movie only plays on the secondary display and not in the presenter layout view and so you have to make sure you’re looking on the screen behind you so that you start speaking at the same time. But when it’s done right, it’s a pretty smooth experience.

The down side, of course, is that you have to do a lot more work ahead of time in prep. For the NSCS demo, I had Tim read off the demo portion of the script while I recorded myself doing the screencast with Snapz Pro X without the sound. It took us about 10 takes to get it just right and in the time span that we wanted.

Keynote Display Preferences

And that’s pretty much how we do it. After all the prep work is done, it’s pretty much up to the presenter to practice it enough for a smooth delivery and to memorize enough of the material so that they don’t have to rely on the script. Before I leave you to make and modify your own demos, I’d like to quickly share with you one last tip. Make sure you set up your presentation display settings ahead of time if you’re using Keynote. Here’s our settings:

Basically, have it set up to Present on secondary display and then definitely check your Display Preferences to make sure Show displays in menu bar is checked off so you can easily make adjustments on the spot. When you’re plugged into the secondary display, then you’ll want to make sure your Mac is not mirroring the primary display (done in display preferences). If that’s done right, your presenter notes will show properly on your laptop and keep you from looking like a spaz when the projector isn’t doing what you expected. Alright, good luck and happy demoing!

Hi, my name is Chris Campbell and I have a color vision deficiency. Like roughly 7-10% of all males, my deuteranomaly makes it difficult to differentiate between some colors, like red and green. Color deficiency, or color blindness as it’s commonly referred to, doesn’t mean that I or people with similar conditions cannot see certain colors. They’re not invisible and I don’t see in black and white (a condition that is actually very, very rare). I can still use crayons effectively, find meaning in beautiful sunsets and even enjoy clear blue skies. What it does mean is that certain colors in the visual spectrum look a lot like one another and so I have a hard time sometimes telling the difference between certain colors and even shades.

Because of this, designing software and interfaces that will also work effectively for people like me takes a bit of concerted effort. Of all the elements of design (line, shape, size, texture, etc.), color is probably one of the most used elements to pass on informational states. This is probably because it allows a designer to say many things without having to change the form or layout of the design. While there are a number of simulators and plugins that can help you “visualize” what a color deficient person might be seeing, I honestly don’t recommend spending a lot of time with them. Instead, I’d like to propose just a few simple guidelines along with plenty of examples to help you effectively ensure that a good percentage of your audience won’t misinterpret your message.

Avoid Using Colors Alone as Visual Cues

Using color and color alone as a visual cue is appealing because it’s usually an aesthetically pleasing and a minimalist design technique. Calls to action and visual cues are critical to interface designers because users, especially on the web, have limited patience and are looking to process information and make decisions quickly. Since the brain recognizes and forms an emotional bond with colors almost immediately, colors are a natural choice for visual cues. Unfortunately, it’s easy to alienate or confuse some of your users when some of those aesthetically pleasing colors look very similar. To point out a few interfaces that use hard to differentiate colors as visual cues, here are a few examples that have given me some trouble.

Bad Cues

As you can see, all three of these interfaces use only red and green (two of the most misinterpreted colors) to convey states or provide information to the user.

• Apple’s iPhone availability indicator uses color alone as a visual indicator. Interestingly enough, they state in their usability guidelines:

“Although color can greatly enhance a user interface, make sure it is not the only source of information. A color blind user may not be able to distinguish between two objects that differ only in color.”

Now, what they do provide is a legend of what red and green are supposed to look like for each state. But for me, it’s still barely possible to match their indicators to the live data, and so the example remains pretty frustrating. It is, however, slightly better than the other two examples.

• Warhammer Online, a video game, and MAMP, a development server application, exemplify the worst culprits because not only do they use similarly contrasting red and green colors as cues, but they don’t give you a reference or legend to help distinguish or label what “red” and “green” are even supposed to look like.

In order to avoid an angry mob of color deficient users, or to just ensure that you and your users are on the same page, here are some aesthetically pleasing interface examples that use text and icons, in addition colors, to communicate what’s going on.

Good Cues

• Dropbox users know the status of their files because of the colored circles and icons attached to each file. The colored circles can be confusing to a small percentage of viewers, but it’s pretty hard to misunderstand what’s going on unless you’re both colorblind and not familiar with their commonly used icons.

• The Wufoo and Versions screenshots pretty much leave no room for misinterpretation because they, like a stop sign, use combinations of shape, color, and a word / icon to give their visual cues meaning and context. You’re sure to leave very little to interpretation when you use three visual cues to convey a single message.

More Good Cues

• Again, Apple uses the hard to distinguish red, yellow, and green orbs as visual cues throughout their OSX windows, but this time they help those with color deficiencies by providing icons whenever you hover over the colored orbs. Since a user is only going to be interacting with those orbs when their mouse is hovering over them, it doesn’t hurt to hide the icons and keep the interface aesthetically pleasing until the user is clearly interacting with them.

• The TiVo interface is strapped for space, and in order to give multiple visual cues using color by itself, a recorded show is represented with a full, green orb, and a show that is currently being recorded is represented with a smaller, red orb. Even if somebody cannot differentiate the colors that Tivo is using in this situation, they can tell the difference between a small and large circle.

Use Contrasting Colors

Of course, as an interface designer, there are going to be times when you do not want to use icons or text as a cue due to space or aesthetic constraints. While I recommend using icons or text when you can, sometimes color and color alone is the most logical way or only choice to convey different information. Maps, for example, often use colors to display separate areas of information about a location. Also, sometimes designers want to indicate state by coloring just the text itself.

If you are going to use color alone, the best way to accommodate for the color deficient viewers out there is to get familiar with contrast. Kevin wrote an excellent article recently on programmatically finding good contrasting colors. Additionally, a couple of great resources about how to choose proper contrasting colors can be found over at lighthouse.org and 456bereastreet, but to give you a quick overview of what works and doesn’t work in my world, here are a couple examples.

Bad Contrast

• This New York Times map is frustrating because the “Yes” and “Did Not Vote” colors are extremely close in contrast, and they basically look like the same thing to me. I wouldn’t even recognize there are four colors being used on that map. And actually, the classic example for bad contrast for the color blind in Wikipedia is this NY Times Map.

• Trulia’s maps are sometimes extremely tough to interpret for me because they not only use red, yellow and green, but they use multiple shades of those colors. I see this a lot of times in graphs and pie charts, and it’s probably the most frustrating example of all the screenshots I’ve documented in this article.

• The red/black and red/green text are sometimes used as hyperlink colors on web sites. They can be problematic because certain combinations are colors that those with a deficiency often have trouble seeing.

Good Contrast

• In this map, the New York Times does a better job because red and blue are easy to differentiate, and while light yellow and light blue can be confused by an extremely small percentage of people, the stripes they use clearly separate the states.

• While this pie chart in Wufoo does use red and green, the colors in this example are contrasting enough to tell apart, especially when viewed directly next to another.

• Here’s another set of text examples that are again a red/black and red/green combo, but they’re more distinguishable due to their higher contrast differences.

Conclusion

For the most part, this isn’t a call to arms. I’m not on a quest to change the world, fight discrimination or demand visual equal rights. As you can see, if you want to avoid making color blunders, all you really need to do is to take a minute to make sure you provide a legend, use icons or words when possible and make sure your visual cues are high contrasting. You probably do not need to run your designs through a color checker and stress over whether or not your interface is going to offend your viewers. In fact, there’s a pretty good chance you’re working near or know somebody with a color deficiency, so having them give your design a once over is a great way to ensure your message is seen properly.

Additional Reading

• Blindness - A series of images that are shown in both normal vision and how they appear to someone with a red/green colorblindness.

• What about Traffic Lights? - Daniel Flück writes about why traffic lights do not confuse him. Wikipedia also notes, “Usually, the red light contains some orange in its hue, and the green light contains some blue, to provide some support for people with red-green color blindness.” This explains why color blind people do not actually need to memorize the location of where green and red lights are located, especially in the dark when you cannot pinpoint the location of where a light is coming from.

• Emerson Moser - In 1990, Moser was Crayola’s most senior crayon moulder and retired after 37 years. After moulding approximately 1.4 billion crayons, he revealed that he is actually color blind.

• Camouflage Detecter - There is an upside to being color blind and it’s that you have the super human ability to detect camouflage like U.S. soldiers did in World War II. That might also help explain why most animals have some form of color blindness.

• Colorblind gaming or: Table Tennis is impossibly hard! - A color blind video gamer explains why Rockstar’s Table Tennis may be the most difficult game ever.

• Seeing Through the Eyes of The Color Blind Shopper - “Many consumers throughout the United States have impaired or limited information processing capabilities as part of congenital or illness-related disabilities, yet their specific problems and needs are often not formally considered by firms, by researchers, or by students preparing to enter the business world. I learned this quite by accident in my own Consumer Analysis class when I gave a routine assignment to my students.”

It’s a fickle world out here on the Internet and I’ve gotten used to bloggers coming and going, but my heart (and feedreader) still feels a deep pang of longing since Kathy Sierra’s exit from the scene over a year ago. Creating Passionate Users was and still is my favorite resource for inspirational outside-the-box ideas for reaching out and exciting our users. And so I was delighted to hear at the beginning of the year that she would be speaking in our neck of the woods in Miami at Future of Web Apps.

And it was fantastic. No surprise, I know, but Kathy Sierra has that rare ability to never disappoint and I think that’s remarkable. She titled the talk, Cognitive Seduction 3.5 (Here’s the audio, transcript and slides), and it was an updated lecture of her developing thesis of how software can take advantage of what science tells us about exciting our mammalian brains. What I want to share with you is one of the things we got out of her talk that’s definitely had a nice impact over at Wufoo.

One of the highlights of the presentation covered the importance of addressing your users’ feelings. Establishing empathy is one of the harder things to recreate over the web and Kathy showed the irony of designing and approaching customer support as if your user is blindly excited to be going through forums and documentation to troubleshoot their issues. There’s a disconnect in those situations because we often forget that real-world interpersonal communication is 90% non-verbal. And while the dream may be to look at face recognition technology for what the future might hold for customer support, that future, unfortunately, isn’t here now.

A Delicate Thing to Ask

The idea I came up with as an alternative was that while we couldn’t passively detect our user’s feelings we could actively ask them. On Wufoo, if you can’t find the information you need to help yourself, we provide a Support Request Form to help us identify and track your issues.

My idea was to simply add a dropdown field of possible feelings to the form and have them select the appropriate one. The tricky part we realized right away was in the copy. The obvious way to ask this is to write “How are you feeling?” But as soon as we wrote it, it felt all wrong. Basically, no customer support person would actually ask that in person especially if that user was visibly angry.

When you get to Wufoo’s Support Request Form, it’s because you couldn’t find the answer on the site and so we knew there was going to be some level of frustration brought to the table when encountering this type of form. Additionally, if you’ve never experienced customer support with our team, then you might also be skeptical about how things are going to play out based on past experiences with other services. Anyway, with that baggage of frustration, “How are you feeling?” ends up sounding condescending and I think it’s because it has connotations and allusions to being in a room with a psychiatrist, which is probably not the person you’re interested in having solve your technical support issues. Even I had a visceral reaction to the language and I made the field. And so after some fiddling, we ended up going live with “Emotional State.”

It was the most neutral wording we could come up with and I think in context of the form, it fit because like everything else on there, it was ultimately about trying to efficiently get to the core of the user’s situation.

Now, this isn’t the first time we’ve taken to heart past advice Kathy Sierra has given on customer support like making our help and documentation as good as our marketing materials. The changes we made there worked out fantastically for us and actually cut down our support requests by 20% as soon as we implemented it. That being said, I didn’t really have any expectations for the Emotional State dropdown. I was curious, but didn’t have a working hypothesis for what was going to happen. Part of this is because I’ve given up on predicting the future since everything always seems to be a surprise when it comes to users, but we were also not planning on changing how we reacted to a support request based on that dropdown (we answer every request as it comes in as fast as we can, regardless of whether that user is paying or not). And some of us were even skeptical that it would be used since we didn’t make any announcements and didn’t make it required on the form.

The Results

We added the emotional state dropdown to Wufoo’s Support Request Form on March 1, 2008. As of the writing of this article (July 16th, 2008), we’ve received 801 support requests since then and 607 of those requests specified an emotion using the drop down, which means 75.8% of our users needing help were willing to share that information. To put that into perspective, the percentage of users filling out what browser they’re using in the form is only 78.1%. So much for users not using it or thinking it’s not pertinent to solving their problems. Here’s the breakdown of the emotions that were collected.

Additionally, not only did people use the field, they were moved by it. We were surprised at the number of emails, blog posts and articles written about this little dropdown. And the thing is, that was never our intention. We didn’t really want to bring attention to something like this, because if there was any magic in it (positive impacts to the user experience), we knew, like all things magical, that the spell would be broken if efforts were made to exploit it. The reason we’ve decided to share our experiences on Particletree is because 37Signals wrote recently about a design decision to not go forward with a similar change to their request form and we felt that was a shame since the benefits we received were greater than just a better understanding of the nature of the user’s request.

For example, if you’re a fan of the writings of Jacques-Marie-Émile Lacan, then you know that written language is often a poor medium for expressing our thoughts. Before we added this drop down, and I never thought about this before we introduced it, our users had to compensate with tone and voice. One of the best things to come out of this is that the language used by our users to describe their issues now are more rational and dramatically less expressive (ie. nasty, filled with capital letters and exclamation marks). Ben McCann explains this best:

GetSatisfaction.com also has this feature, which is really nice when you’re upset because you can express that without getting nasty. I’ve been in many situations where I’ve only gotten help from the customer service reps if I’ve gotten upset or angry at them. Now it’s almost my default to be angry when talking to someone in customer service because of how many times I’ve been ignored while being polite. However, when I see something like this it calms me down because I get the sense that the company will listen without me having to be a jerk. I much prefer being able to leave a courteous and informative message and I’m sure the people working in customer service prefer it as well.

And he’s right, when it comes to customer support, I’d much prefer to deal with Mormons over prison inmates. A request that’s polite makes doing what you need to for your customers, which is often repetitive and frustrating, noticeably more pleasant. In our company, where every employee is required to handle a percentage of customer support, that’s a big impact on the everyone’s state of mind during what’s usually considered a grind in other organizations. Also, when 70% of your support requests all of a sudden become nicer, when the calls for help are noticeably more polite, you tend to go the extra distance. It’s a self-serving cycle that couldn’t have been predicted if we didn’t actually try it and honestly shouldn’t be underestimated when it comes to providing quality customer support.

Another thing that’s surprising to me in hindsight is what appears to be the relative honesty of the feelings expressed. If you’ve ever been to an emergency room, one of the first questions they ask you is to rate your pain on a scale of 1 to 10. It’s obvious that they use this to triage patients and so veterans of the system will exaggerate their pain level to reduce the time they spend in the waiting room. Chris had first-hand experience of this when he injured his ankle and the boy scout in him wouldn’t let him utter a number higher than 3, which resulted in a 6 hour wait for an xray while level 8 ear infections and pink eyes plowed ahead of him. Now, our users didn’t know that we were NOT going to use the emotional state as a way of setting priority to a request, but it turns out, for the most part, most people did not try to game the system. One theory for that is there wasn’t a feedback loop for this kind of behavior. Because we didn’t act differently, our users didn’t react to the dropdown as a variable to hack.

Final Thoughts

One thing I’d like to note, though, is that this is not a plug-and-play solution. I hope no one takes from this article that all you need for good customer service is to add a dropdown like this to your support request form. I truly believe that the motivations have to be genuine and part of a holistic approach that values your users’ satisfaction. If you don’t believe or really care about your users’ feelings, then this is probably going to backfire on you. The most important part of a request form is responsiveness (getting the problem addressed quickly and fixed). Once you have that foundation laid, then I would recommend assessing the emotional impact of the situation.

I know there are pessimists out there that think this touchy-feely stuff is bound to annoy more people than help them, but our users have responded surprisingly positive to us just asking the question. It’s about comfort. I think it might be that programmers, engineers and hackers are usually all about efficiency. You don’t need empathy to fix a bug or answer a question. It’s not a class they teach in Computer Science. But at Wufoo, we’ve come to discover that knowing how a person feels is one of the first steps towards humility. If our users are constantly confused or upset about how to do something in our application, then obviously that’s a failure on our end. Humility helps us accept our short-comings and make the changes necessary or help the person in a way that provides, in the end, a satisfying experience and a lasting relationship. And while that’s not something you need to fix your software, it is a vital part of running a good business.

Hi everyone, my name is Alex Vazquez and I’m one of the new additions to the Wufoo Team. Because Chris, Kevin and Ryan prefer OSX and work primarily with PHP and JavaScript, they naturally wanted me to try moving over to their favorite development environment, Textmate. In this article, I thought I’d share some of my experiences making that switch from the perspective of someone used to handling large IDEs.

The right development environment can save a programmer countless hours and is like a hammer in the carpenter’s tool belt. Since my background was in Java, my preference was for large sledge hammers and my development environment of choice was the de facto Java IDE Eclipse. It has a number of amazing features like autocomplete, refactoring and hundreds of plugins for every task imaginable. It’s no secret Java requires mountains of code, but Eclipse was made to move mountains.

In the beginning, moving over to Textmate felt like I was given just paper and pencil to do my job. The truth of the matter is that IDE lovers like myself usually imagine something like Notepad when a developer mentions that all they use is a text editor to write code. This is usually what we’re thinking:

Okay that’s cute, but seriously where do you do your development? You’ve got to have some real tools somewhere. I mean they do give Eclipse away for free you know. Like free as in free beer.

Aesthetics

While my conversion to Textmate was a bit slow, one of the first things I quickly fell in love with was their Twilight theme for color coding programming syntax.

If Twilight doesn’t quite cut it for you, I highly recommend trying out the Vibrant Ink color theme by Justin Palmer. It was nice to know that if I was going to be using something “dumb” it was at least going to look pretty. In fact, the entire application is very beautiful, which is one of the nice side-effects of working on a Mac. I also found that the details in a number of simple features like ‘Find in Project’ were really well done.

Shortcut Keys

Learning Textmate’s shortcut keys went a long way to making me comfortable with the editor and speeding up my development. Shortcuts work best when they feel like a reflex. I knew it was going to take some time to undue years of habits cultivated in another environment and so I prepared myself to be patient during the process. Because Textmate has such a minimal interface, using shortcuts is actually a crucial part of executing functions and commands efficiently in the application. Here are some of my favorite shortcuts in Textmate:

Commands I’ve Committed to Memory

Commands that are Nice to Know

For a great sheet of a lot more shortcuts, check out the Textmate manual.

Plugins

Because Textmate’s API is very extensible, the plugins developed by outside parties are both varied and powerful. Two plugins that went a long way to making Textmate feel more complete to me were the Missing Drawer and SVNMate.

The Missing Drawer plugin moves the file browser out of the drawer interface and into a side bar built into the project window so that it looks like a seamless extension of the editor.

SVNMate visually displays the SVN status of files and directories in your file browser using color and shape coded icons. An integrated visual system likes this is really nice since it helps me avoid having to go back and forth with an external SVN client to see what I’m currently modifying. For a list of other plugins available for Textmate, check out the Plugin Wiki Page.

Bundles

The true power of Textmate comes from its bundles. Bundles are snippets of code that help to extend the functionality of the application as you edit text. They’re usually triggered by key commands and tend to be language specific. It wasn’t until I learned about how to use and create commands and snippets, that Textmate became more than just a pretty text editor to me. Textmate has over a hundred available bundles. There’s so many that it actually helps to hide the ones you don’t use regularly using their Bundle Editor.

The genius of bundles is that they can be written in any of the major scripting languages (PHP, Python, Perl or Ruby). Developers from any language can easily extend the functionality of Textmate within minutes of learning how Bundles work. The entire Unix shell is even at your disposal, including GREP, SED and AWK, which are all right there and accessible from the text editor. Textmate also provides tons of examples so you don’t have to start from scratch. You can even view the source for the built-in bundles right in their Bundle Editor, although most of them seem to be written in Ruby.

A perfect example highlighting the beauty of bundles is the TODO bundle. A commonly excepted comment in the programming world is TODO, which notes tasks that still need to be done.

/*
TODO - Escape all output from this function.
*/

Development environments then take all of those comments, and combine them into one todo list with clickable links back to the code. This is great, but since the TODO comment is so common, a lot of third party libraries use it generously throughout their code, which means your nice list has 100’s of items that you will never touch. To solve this, just go to the TODO bundle and select preferences. You can ignore TODO, and make your own such as ALEXTODO, TIMTODO and RYANTODO. Then, in your code place:

/*
ALEXTODO - Escape all output from this function.
RYANTODO - Implement error handling.
*/

This will provide us with two todo lists, separated by developer, and with no todo items from third party libraries.

While this isn’t earth shattering, it is pretty convenient. Thanks to the simplicity of the bundle system, it allowed us to tweak the source code to meet our specific needs with little hassle. In comparison to Eclipse, extending Textmate is a breeze.

So far, I’ve written a shell command that opens my SVN client, SVNX, without leaving Textmate and a command that formats text into a PHP comment block using Wufoo’s standard format. I did it in a few minutes and they’re both written in PHP. For more information on implementing Textmate commands in PHP, I recommend Cirian Walsh’s article on the subject. You’ll want to take a look through the source, text and PHP bundles functionality. With just a few custom commands, Textmate has quickly and easily become a personalized PHP editor for me.

Final Thoughts

Right now, the possibilities with Textmate seem limitless. The simplicity of the application and the ease of its extensibility is too inviting to ignore and I’m very excited about seeing how far I can push this little editor. It’s beautiful, lightweight and speedy—attributes that weren’t associated with my old Eclipse IDE. Because Textmate has a very strong following, there’s a lot of blogs and resources covering its use. Two must reads are Circle Six and the excellently executed Textmate manual. If you still can’t get enough after that, here’s some links to help you get the most out of my new favorite environment :

• An In Depth Guide Covering The Basics of Using Textmate.
• Our favorite Textmate screencasts on html tags, text transformations and column selections.
• Textmate 2 Rumors and a Video of Codesense in action, which will only be available in Textmate 2.
• And if you’re hardcore, definitely join the Textmate discussions at irc://irc.freenode.net/##textmate.

In preparation for the redesigns and overhauls we implemented in Wufoo, I took some time to revisit a few HCI (Human-Computer Interaction) fundamentals with the hopes of gleaning something new out of the decades of research dedicated to making interfaces easier to use. One thing that surprised me was how most of the material was pretty dense, heavily geared towards mathematicians it seemed and written in the impenetrable language of the academic elite. You’d think that if they’d really wanted to make an impact (especially on designers), they’d create documents that were a bit easier to digest.

Back in school, I remember that it wasn’t until I started taking classes in physics that calculus made any kind of real sense to me. I just need diagrams to function. In that spirit, I thought it would be nice to go over Fitts’s Law, a staple in the HCI diet, with a few visuals to explain both the concept and why it’s ideas are a bit more complicated than most would have you believe.

Math of the Obvious

Published in 1954, Fitts’s Law is an effective method of modeling the relationship of a very specific, yet common situation in interface design. That situation involves a human-powered appendage at rest (whether it’s physical like your finger or virtual like a mouse cursor) and a target area that’s located somewhere else. Here’s diagram the first:

Mathematically, Fitts’s law is stated as follows:

MT = a + b log2(2A/W)

Basically, that means that the time to acquire a target is a function of the distance to and size of the target. It seems like a no brainer. The farther you are and the smaller the target, the longer it takes to move the cursor and point at said target. However, Tom Stafford said it best:

“Although the basic message is obvious (big things are easier to select) it is the precise mathematical characterization that is exciting, and that this characterization includes a logarithmic function - which means that the shape of the relationship between size and reaction time is curved so that small increases in size for small objects make it much easier to select them (whereas small increases in size for big objects don’t make that much difference). And the same applies for changes in target distance.”

Size and selection times: Fitts’s Law

Just to bring it into the real world, this makes sense since a penny is a lot easier to point at than a freckle and a house is just as easy to point at as an apartment complex. So the next time you optimize your web site based on Fitts’s Law, remember that if your link is already huge, making it “huger” will not significantly increase the speed at which one can access it. However, making tiny links a little bigger does make a difference.

Fitts’s Law is Made of Lines!

Wanting to find practical lessons from Fitts’s equation, interface designers have derived a few rules of best practice to take advantage of one of the very few laws of human interaction. One rule, The Rule of Target Size, combines ideas behind Fitts’s Law and Hick’s Law (a law I’ll talk about on a later date) to state that the size of a button should be proportional to its expected frequency of use. Bruce “Tog” Tognazzini of Apple interface fame even developed an excellent quiz to explain how Fitts’s Law can be used to develop rules to drastically improve operating system interfaces.

Before you go and follow these rules blindly in your applications, I want to remind you that Fitts’s Law describes a very specific situation. There is an assumption that the movement from the starting position is rapid and aimed, which means it’s always in a straight line and confident (starts with high initial velocity as if there were no other targets and you knew exactly where you needed to go). Also, I’ve seen a lot of people think Fitts’s Law describes the following situation:

However, in the equation shown above, there’s no variable for height of the target area, only width. And so one of the most talked about limitations of Fitts’s law in HCI circles is that it predicts movement in only one dimension. In Fitts’s original experiments, he actually only tested human performance in making horizontal moves toward a target. Both the amplitude of the move and the width of the terminating region were measured along the same axis, which means the model it describe looks more like this:

Now, if we were to base link size optimizations solely on Fitts’s Law and we assume that vertical and diagonal movements can be described using the same equation, then the ease at which you can point to a specific target actually depends on where your starting position is in relation to your target.

In the example above, the cursor on the right will technically have an easier time selecting the target than the cursor on the left since it will have more “target width” to work with. Notice that Fitt’s Law would work fine for circular targets since the width to the center of the object would be the same from all angles. However, it becomes less accurate for rectangular targets and even more so for irregular objects. In the next example, we’ll look at two attempts to optimize the target area of a link by increasing rectangular dimensions.

The second figure increases the width of the target box and the third increases the height. As you can see, based on where the mouse cursor starts, not all size increases on a rectangular target result in an easier target acquisition, which could be significant for web designers considering all CSS designs are based on the Box Model.

Physical vs Virtual Pointing

Hundreds of derivative experiments have been performed since the publication of Fitts’s findings. One interesting paper from 1996 by Evan Graham and Christine MacKenzine, analyzed differences between how well we pointed at objects in real space versus objects on the computer screen. They show that the movement from the starting point to the target area could be divided into two parts: the initial high velocity phase and a deceleration phase.

In their study, they discovered that the first phase was only affected by the distance away from the target. The scale of the display nor the size of an object didn’t make you approach it more quickly from the start (bigger links don’t make you more eager). The phase that actually affects the time to select a smaller object at the same distance, is in the deceleration phase. Now, here’s the “interesting” part:

“The difference between the virtual and physical display is apparent only in the second movement phase, where visual control of deceleration to the smaller targets in the virtual task took more time than in the physical task.”

Basically, links and buttons on a screen are harder to point out with your mouse than with your finger. And the problem with mice apparently is not in their ability to get to the target, but in our ability to decelerate accurately with them. Apple, I eagerly wait for the release of some multi-touch monitor goodness.

Rule of the Infinite Edge

It turns out that computer monitors add a very interesting twist to Fitts’s model of target selection, because they have something called “edges.” Jeff Atwood of Coding Horror actually explained this rather excellently last year in an article on Fitts’s Law and Infinite Width. Because a pointing device can only go so far in any direction, targets at the edge of the screen technically have infinite target widths as illustrated below.

For an operating system and on any full screen application, these edges are usually considered the most valuable real estate since they are technically the most accessible. Not only do they have infinite widths, they also don’t require the user to have a deceleration phase when they approach these targets, since the edge of the screen will just stop them. This is also why it’s incredibly fast and intuitive to assign actions like Expose and Dashboard to the corners of a screen.

Unfortunately, web applications do not get to benefit from the Rule of Infinite Edges. Having the limitation of needing to run in a browser window with borders, it’s of little value according to Fitts’s Law for web designers to place buttons and links at the edges and corners unless the browser is running at full screen, which seems to only happen for kiosk applications.

This also might explain why the interfaces of Web Operating Systems will never be as good as those that can take advantage of the entire real estate of your monitor.

Fitts Still Rules!

The few limitations of Fitts’s Law that I’ve presented here are not an attempt to have you throw its lessons out the window. My hope is that by illustrating some of the debates, it’ll show you how something as simple as pointing at something is just as relevant and debatable now as it was over 50 years ago. And while it’s technically not an accurate description of most interface situations—humans don’t always move confidently to a target, we don’t move in only straight lines, there are usually several targets that can confuse us and target areas are almost always two dimensional—research that has created a more accurate mathematical model that compensates for 2 and even 3 dimensions, hardware noise, human error and a host of other factors doesn’t seem to change the fundamental truths behind Fitts’s rather versatile equation:

“Fitts’s law has been shown to apply under a variety of conditions, with many different limbs (hands, feet, head-mounted sights, eye gaze), manipulanda (input devices), physical environments (including underwater!), and user populations (young, old, mentally retarded, and drugged participants).”

In the end, the big idea I’d like designers to take away from this article is that the challenge of software application design is so complex and filled with so many variables, that blanket solutions derived from Fitts’s Law should be used cautiously. With the increasing size of monitors, the rising popularity of variables that increase mouse acceleration and technologies that alter how we scroll through large screens, it’ll be interesting see how software designers will take advantage of tools that let us augment our ability to close large distances quickly.

Most of the debates on the importance of design in business are usually focused on how aesthetics affect a business’s bottom line. Whether it’s Facebook vs Myspace or Microsoft vs Apple, the argument is a lot like the infamous invisibility vs flight hypothetical. With absolutely no data, it can be argued on several levels and, in the end, often say more about the person than the companies involved.

On our team, our experiences and workflow have brought about a richer appreciation for the role of good design in a company. While we do like to focus heavily on the look and usability of our products and experiments, we believe design’s greatest value to a business goes deeper than the idea that it’s a glossy exterior that attracts customers. In an interview with Fortune Magazine, Steve Jobs said:

“Design is the fundamental soul of a human-made creation that ends up expressing itself in successive outer layers of the product.”

It’s a little romantic, but we believe the greatest asset of this “fundamental soul” is the ability to dramatically influence the quality of a product and the culture of a company before production even begins. We think it’s a shame when developers debate the merits of design after the core product is already completed, because it misses out on design’s true potential: to impact your internal business. Good design in our company doesn’t just sell products. Good design fosters collaboration, communicates strategy, sets expectations, improves the efficiency of a team, and most importantly inspires and motivates like nothing else.

Setting Expectations

Seth Godin recently mentioned in a post on expectations that when it comes to business, promising big and delivering bigger seems to be the only reliable strategy. To gain buzz you need to set expectations high. To gain and retain customers, you need to surpass those expectations on a regular basis. A great way to start is by setting the table for quality early on inside your organization and one of the best ways to do this is through design.

Numerous research studies have illustrated the impact of expectations on individuals and groups. The Pygmalion effect, which is more commonly known as the Teacher-Expectancy effect, describes situations where students perform better than other students simply because they are expected to do so. In 2003, J. Sterling Livingston wrote an article for the Harvard Business Review about the Pygmalion effect in management. He explained that “if [managers] are skillful and have high expectations, subordinates’ self confidence will grow, their capabilities will develop, and their productivity will be high.”

Garr Nolds, an associate professor of management at Kansai Gaidai University and an ex-Apple employee, believes that these high expectations for an organization should be set with design.

“[Companies] are beginning to preach design internally and demand great design, not just of the product-development teams, but of all departments. If an organization’s true brand is actually inside the company, then we sure as heck better make sure we have an internal climate that preaches great design and lives incredible design everyday.”

Why Design Matters

Two Types of Quality

One culture that does a fantastic job of incorporating design expectations into business practices at every level is the Japanese. Their version of total quality management, which is a management strategy aimed at embedding awareness of quality in all organizational processes, is heavily dependent on aesthetic values. The relationship between design and quality is very close for the Japanese, who believe that in order to have a quality product or service, it needs to be created in a way that satisfies two different ideas of quality. The first, atarimae hinshitsu, which is roughly translated as “taken-for-granted quality,” is the idea that things will work as they are intended. The second, miryokuteki hinshitsu, which means “enchanting quality,” is the idea that things should have an aesthetic quality that appeals to a person’s sense of beauty. Here’s a simple example to help make it a bit more clear:

atarimae hinshitsu
A pen will write.

miryokuteki hinshitsu
A pen will write in a way that is pleasing to the writer AND leave behind ink that is pleasing to the reader.

—Wikipedia on miryokuteki hinshitsu

For the Japanese, the product or service isn’t good enough when it just works—it needs to also work elegantly to be considered of a sufficient quality that makes it presentable to the consumer. This belief is embedded deeply into Japan’s corporate culture and permeates everyone’s values from management to the workers on the factory floor. What Nolds and Japanese companies like Toyota understand is that to be effective in creating values that expect quality work from everyone on a team (not just designers), you have to instill these design values from the beginning and at a fundamental level that presents a commitment to beauty and elegance for everyone and at every step in the process. When you do this, you find your team rising not to the challenge or your competitors’ cries, but to the designs presented before them.

Design Helps Get Things Done

When you provide engineers with a design from the beginning, in addition to setting expectations of quality, you provide a holistic understanding and strategy for what needs to be accomplished. Good prototypes show exactly what the product is supposed to look like, and which features need to be created without getting in the programmer’s way.

“…without product design, our manager’s two fears remain unquelled. She has not established whether or not the users will like the product, which indeed leaves its success a mystery. Nor has she established what a ‘complete’ product looks like, which leaves its completion a mystery.”

Alan Cooper

Good designs that are established at the start of a project prevent the programmer from leaving features incomplete or straying off course to create “neat” features that may turn out to add unneeded complexity and reduce the usability of your products. Incomplete features hinder productivity and when you remove a programmer’s cool features after they’ve already created them, you open up the potential for arguments and bruised egos. The sunk cost fallacy might be one of the most difficult concepts to accept when it’s your time and energy that has to be sunk.

Most of the programmers we know seem to have a common problem where they love to start challenging projects, but have a hard time following through and finishing. You may disagree on exactly how detailed a functional spec should be, but when your engineers are also acting as your interaction designer, chances are your product is going to take longer to complete and you won’t end up with the results you intended. There’s actually a common saying that goes something like this:

“The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time.”

Ninety-Ninety Rule

Our team is definitely no exception, and while we have no problems working on features that excite our users, the boring features like backend account management or even documentation seem to be a real drag. To help speed up the work on boring or tedious projects, we often turn to design to get us going. To illustrate what I’m talking about, here’s two screenshots showing the old administrative interface compared to the new design proposed by Kevin:

We couldn’t help but want to actually make it work. Well-designed comps show you what could be accomplished if you would only get off your lazy butt and bring the design to life. Not only does design get us started, but we find ourselves finishing projects that were well designed ahead of time much faster than projects that didn’t have a wireframe or prototype (like our billing system). We’ve come to learn that it’s hard to motivate technical people, including ourselves, through money, colorful toys, or gigantic monitors. We try, instead, to have a design ready for everything we’re about to approach so the motivation for accomplishment is instilled by our need to see something that looks cool come alive.

A good design also has the ability to remind us that we’re working on something worthwhile, which is another way design can help fuel productivity. This seems to be a common motivational factor for programmers. Here’s a few quotes from programmers discussing the problem on how to motivate programmers in the Joel on Software forums :

“If they’re new meat they haven’t really had the feeling of shipping a product and seeing it in the real world help somebody. That’s what gives me the biggest kick.”

“I think the inverse of that is why most programmer’s get so fired up about not wanting to ship crap. Having been involved with a couple of projects that were total garbage I can’t tell you how horrible it is to continually have to apologize for the complete piece of shit that is sitting in front of a user.”

By designing first, you know that you’re working on a product with a soul and not some middle manager’s steaming turd of a project that they’re just trying to ship out the door to make their quarterly bonus. Programmers do not want to work on garbage and when they see something that’s useful, real, and worth accomplishing, they’re internally motivated to not only start but to also finish.

Conclusion

Deep down, we all have a desire to be proud of our work, and design is a great way to set the stage for excellence within your organization. When you start out with a beautiful and awe inspiring wireframe or prototype, your expectations about that product and everything associated with it is expected to also be beautiful and awe inspiring. If the initial expectations for a web application are low by bad or no design, then bad practices seem to find their way into the code, the web site marketing, and even the attitudes toward customers by employees. When you start with great design as a foundation, there is a snowball effect on the quality and execution of a product from start to finish.

In a healthy business culture, what’s good for the company and for customers comes together and becomes the driving force behind what everyone does. Whether or not design results in a few more units sold can be debated, but I don’t believe we’d argue about the importance of instilling pride and values in your workforce. This is where the true value of design lies.

And that’s when it got me thinking. What were the problems to the masses that got them switching over in the first place? Last year I wrote a bit about The Change Function, a concept that proposes that people move over to new products based on the relationship of two variables: Perceived Crisis and Total Perceived Pain of Adoption. And at the height of the Firefox craze, there was a a very real crisis across the Internet and it came in the form of viruses, pop-ups and spyware.

Between 2003 - 2004, we were at the peak of the crisis with the Internet suffering from spam terrorism. During the height of conversions, Firefox was one of the first popular solutions for making the web usable again. Yes, it loaded faster and sure it had tabbed browsing, but the biggest difference of opening a web site in Firefox versus Internet Explorer 6 was that you weren’t ashamed to do so around children and colleagues at work.

Toolbars Killed the Firefox Star

In 2005 something happened. Pop-ups and spyware started to become less of a problem. Here’s a graph courtesy of Google Trends that shows the decline in users searching for popup and pop-up over the last few years.

Firefox was just one solution of many that were released by everyone and their mom to help make the Internet safe again from popups and spyware. There were countless programs created to help fight the good fight. Even AOL pitched in, releasing AOL version 9.0 and AOL Spyware Protection in 2004. My guess is that Google Toolbar, Yahoo Toolbar, MSN Search Toolbar and Windows Live Toolbar were probably the most popular and they all patched up IE6’s biggest problem (in the eyes of users) by blocking popups.

In regards to the spyware hysteria, here’s a look at the activity involving searches for the term spyware in relation to the popup searches in Google Trends:

To give you some context that might explain things, at the end of 2004, Microsoft finally released Windows XP Service Pack 2 and if you look at the feature list, you’ll notice the first one highlighted is “Internet Explorer Pop-up Blocker.” In January 2005, Microsoft launched their Anti-Spyware and Anti-Virus Tools, which was offered for free and seeing that it came from a familiar (and some-what) trusted source—it too, was downloaded like gangbusters.

And so we shouldn’t be surprised that in the fall of 2005, a number of reports started coming in from bloggers wondering about the slowing of Firefox adoption. By the end of the first quarter of 2006, we can see that spyware was on the slow decline in the minds of users of the Internet. By the time Internet Explorer 7 came out in the fall of 2006, the crisis was basically over and the masses were already content customizing their favorite web 1.0 application (MySpace), which worked just fine in IE6.

One might even argue that the arrival of IE7 was way too late and probably explains why the browser’s adoption rate (and I’m guessing here) follows the adoption rates of Vista and those who are willing to let SP2 just install it for them. What’s interesting is that Microsoft should be thanking Google. The company that had done the most to encourage Firefox adoption, might have also done the most harm with their, well…excellent toolbar for IE6. In fact, Google’s toolbar and desktop search applications pretty much launched the whole toolbar battle that’s been raging between the trinity (Yahoo, Google and Microsoft). My bet is that for every toolbar that was installed on Internet Explorer 6, it effectively halted the need for that user to convert to a different browser.

The Effect of iTunes and BitTorrent

If you can remember, the primary delivery mechanism of a number of spyware and popup programs was through file sharing networks like Kazaa and BearShare. The need of the public to search and download millions of songs and videos (and porn) was exploited by numbers of malicious advertisers and web sites by uploading tons of self-installing programs disguised as desirable media. File sharing programs themselves even turned out to be spyware.

In April of 2003, which was in the middle of this crisis, Apple launched the iTunes Music Store, a legal alternative to downloading music that people seemed to be happy to see just work. It took a few years, but by the summer of 2005 over half a billion songs had been downloaded through the iTunes. Following their lead, a number of music download services launched and the demand for music and videos was met with a safe, perceptively cheap and extremely easy outlet.

In addition to a legal alternative, traditional file sharing networks were also being replaced by a new mechanism for media transfer: BitTorrent. What’s interesting about the torrent community, is their dedication to quality. The most popular torrents are carefully cataloged and meticulously labeled and compressed. It’s a relatively safer community than traditional file sharing networks based on Gnutella clients and the worst thing you’ll come across in your downloads are poisoned torrents from HBO.

While Bram Cohen, implemented the first versions back in 2001, it wasn’t until 2003 that the protocol became hot when it was combined with RSS to create broadcatching. Popularized by Steve Gilmor’s article, which was written for Ziff-Davis (they own PC Magazine and a number of other popular media sites), the idea that you can just subscribe to your favorite shows and watch them the day after they aired captured the imaginations of a large number of users hoping for the convenience of TIVO without the costs.

And so, in addition to spyware being blocked by toolbars and other helpful applications, the channel by which spyware and viruses were infecting browsers and computers, was replaced by alternatives that produced clean downloads. The crisis that gave birth to Firefox’s rising popularity was extinguished on two fronts and from unexpected sources.

What about Safari?

In regards to Safari, the increased adoption there (like Internet Explorer 7) is probably tied to the increased market share Apple’s computers are making in the PC market. I find it interesting that some people think Apple’s release of Safari for Windows is a serious attempt to gain browser adoption on the personal computer. The thing is nothing has changed. The factors that lead users to switch to Firefox aren’t around anymore and so what real hopes does Apple have for people to switch to Safari?

Safari is entering a crowded space and is far from being above and beyond better than its competition. Let’s face it, Firefox is a great browser with a great development team behind it and beating it on quality and innovation will be tough. If anyone understands the importance of a vacuum or crisis to cause users to switch, Apple certainly does. The iPod, iTunes Music Store and iPhone were are released in those conditions. Knowing this going in, I’d like to argue that Steve Jobs has no real passion about growing Safari usage on Windows. If you listen to the keynote when he announced the beta, he was even half-hearted about his enthusiasm for Safari making some headroom in the market.

No, browsing on the Internet on a personal computer doesn’t suck anymore. Where it does suck, however, is on the cell phone. Safari isn’t leaps and bounds better than Firefox or IE7, but it is ridiculously better than every mobile browser out on the market today. So the serious strategy, I think, for Safari is to grow it like iTunes, which piggybacked off the iPod. Make the hardware associated with it (iPhone) number one in its market and then by it being the default and only browser on the system (one of the adoption factors I list below), you spread your software better than if you were to try and compete directly with other vendors. Considering the fanfare iPhone has received so far, it’s hard to believe it won’t take off like the iPod.

Here’s what I think about the release of Safari on the Windows platform. It has less to do with attempting to actually be a competitor in the browser space as it does with giving developers a tool to accurately test and build iPhone applications. Steve Jobs said there wouldn’t be an SDK for the iPhone because he essentially just announced it with the release of Safari 3 for both operating systems, which is, for the most part, exactly what he said. Apple is betting that Safari is going to be the #1 mobile browser because the iPhone is probably going to be the #1 cell phone. And if the world is moving towards an Internet powered by mobile broadband, then developers (knowing how the story went with IE6) are going to make sure their sites and web applications works on the #1 platform.

In Conclusion

My theory of browser adoption is built on the foundation that your typical user is incredibly lazy and hates change. There are really only two factors driving browser adoption.

• Was it the default browser on the system?
• Does it make browsing the Internet suck?

Now, you may think IE6 obviously makes browsing the Internet suck because it doesn’t have tabs and tends to implement CSS and JavaScript poorly. But that’s because if you’re reading this site, you’re probably a designer or developer. Remember: ugly, buggy and slow aren’t enough to make users think it sucks enough to switch (think MySpace and Windows). In hindsight, the best thing to happen to Firefox was probably the rise of file sharing networks, spyware and pop-ups. Basically, everything that made the web suck. Everything that made the web a safer place to browse, made Firefox less relevant and quelled the urgency that made an alternative to IE6 a necessity.

What I find most interesting is that web developers (specifically those of the standards and Web 2.0 variety, which includes myself), were so excited by the Firefox momentum that we were convinced that it was a revolution. We actually thought the masses were starting to believe Internet Explorer was Satan incarnate. Just goes to show that it has to be in your face popups of wangs and cooters to make you download something different.

Some of the most difficult questions about a startup have to do with making predictions about the future. Estimates are just part of the game if you’re trying to manage the precious few resources you have at various points in the beginnings of your company. The problem is we’re all pretty terrible about extrapolations because if you’re an entrepreneur, by definition, all your estimates will be wildly optimistic.

Making mistakes about your skills and speed can lead you to hold off on a billing system until the last minute or estimate that you have 1 month to launch when you really have 4. And if you’re not careful, hubris might kick in and have you predicting a $1 million in revenue within 8 months of launch.

In this feature, we’d like to help you minimize those mistakes by dissecting 4 very different web application companies that are at varying stages of their life cycle. In addition to age and size, these companies vary in their business models, programming languages and views on approaching the web as a platform. Specifically, we’ll be sharing code line counts, business processes, conversion rates, support requests revenues per customer. It’s good stuff and we’re hoping it’ll help you identify some trends that’ll make your predictions a bit more accurate.

The Participants

Here is a quick overview of the companies featured in this article:

• Wufoo is our web application. It’s an online HTML form builder that helps anybody collect information over the Internet. When you design a form with Wufoo, it automatically builds the database, backend and scripts needed to make collecting and understanding your data easy, fast and fun.

• Blinksale is used to invoice clients for services or products sold. Blinksale is used by attorneys, accountants, designers, IT professionals, software developers, journalists, contractors, engineers, architects, videographers, and more. Basically, if you need to send invoices, Blinksale can work for you.

• FeedBurner is the leading provider of media distribution and audience engagement services for blogs and RSS feeds. Their web-based tools help bloggers, podcasters and commercial publishers promote, deliver and profit from their content on the Web.

• RegOnline is one of the largest online registration systems on the web having processed over 3,537,094 registrations for more than 49,133 events worldwide. Over the past eight years they’ve invested over 20,000 development hours into the system and is considered one of the most mature and robust event registration systems available today.

The Basics

Looking over the basics, everything is fairly standard. The longer a startup has been around, the more employees it has, and programming language alone will not make or break a company.

The largest discrepancy is with time to launch. All companies were started with 3 or less people working on the code, but RegOnline in particular took the tough route: bootstrapping. The original founder worked a full time job, and wrote the code in his off time. This approach is definitely more demanding and requires much more dedication than receiving funding or backing by your freelance firm, but it can be done. All participants agreed that language had little to do with time to launch.

Code Line Counts

Not surprisingly, the longer a company has been around the more code it has. Experience also shows that once you are past your base set of code, the percentage dedicated to server side code starts to increase. This is primarily due to added complexity of features and other enhancements (spam protection, security, error handling, etc.) that do not necessarily have an interface element attached to them.

As far as the original interface is concerned, it’s interesting to see how Wufoo, the youngest company, has 29% of it’s code invested in JavaScript with the second highest line count for that language among all 4 companies. Arguably, this trend will probably continue with other young “Web 2.0” apps as they adopt more Ajax intensive programming techniques.

As far as choice of language goes, all 4 companies are satisfied with their choices. There are a few minor complaints — FeedBurner wishes to some extent that the lighter, simple web interface tasks were in a different language (but they’re just fine with the heavy processing in Java), while RegOnline is aware of the fees that need to be paid in order to use a Microsoft based development platform — but overall, everyone is happy. In the end, it seems that choosing a language that you’re comfortable with can result in less lines of code and a quicker development time.

Line Counts per Business Process

The goal of this section was to uncover any task that might be overlooked. When writing a software product, the tendency is to focus 100% on the application. Items like support, marketing, and especially billing never cross your mind — in addition to the rest of the underbelly.

While these business processes seem to only contribute towards 10% of the code base for the two most established companies, it is important to recognize that the core for the business code has to be in place during launch, if not shortly after.

Support Requests

Before even looking at the numbers, it is worth noting that support is more demanding than most would anticipate. While multiple things can lead to support requests (poor code, bad interface, complexity, lack of documentation, etc.) what seems to matter the most to customers is how quickly, friendly, and accurately you handle it.

A few successful approaches to reducing the number of requests that have worked for the above companies are the introduction of the following:

• Forums
• Knowledge Base
• Documentation (with videos & screenshots)
• Useful, custom tools for support staff

The amount of time dedicated towards improving support can speak volumes. A majority of the panel agreed that support requests tend to lean towards “How do I …” and “It would be cool if …”, which is why when RegOnline established their knowledge base they saw a huge decline in tickets of that nature. Personally, I am in agreement that this type of support reigns supreme, but be aware that heavy use of JavaScript (with JSON) and foreign characters will also keep you up for quite a few nights.

Conversion Rates

Getting users is one of the more stressful aspects of a startup. Without users, you have nothing. And contrary to grand expectations pre-launch, those users are tougher to convert than anticipated. In fact, 1% is a fairly standard number to expect. So of 100 people visit your homepage, 1 person will become a paying customer.

Free accounts can also generate revenue through ads, awareness, and link backs, but the amount of free accounts you have does not necessarily increase the conversion rate that leads to getting paid. Blinksale has the highest conversion to free ratio (even though their signup form has 20 fields!), but they still come in at 1% paid. On the other hand, RegOnline has a very limited free plan, which shows a significant drop in free signups along with a much higher free to paid conversion.

To place more emphasis on the difficulty to convert, we can look at the conversion of beta testers and free advertisements for Wufoo. After a few months of limited beta testing, everyone who provided active feedback was given a free account. Of 7000 other testers, less than 1% became paying customers even though they were given a 50% off lifetime discount. Similar to that, ads that we place on both Particletree and on free forms result in approximately a 1% conversion to paid.

Average Revenue per Customer

The three companies listed all rely on monthly and/or usage fees in order to make money. Obviously, RegOnline is in an enviable position here. A few things that may result in their revenue is the maturity of their product (and the number of features they have available) along with their 10 year reputation. Not to mention, their customers are all making money (event registration), so they are willing to spend money in order to make money.

Wufoo and Blinksale have a similar approach in that they are trying to get a swarm of users paying less money. The goal is to reach some of the smaller businesses that are more reluctant to jump into a big purchase, and also to increase word of mouth through the volume of customers. Finding the target price to charge for your product or service is no easy feat. When Blinksale first launched, they realized they underpriced their product, and had to make the appropriate adjustments later down the road. The grandfather adjustments worked out for them, but time and programing effort had to be provided to solve the problem.

Equally challenging is how to raise the average price per customer. There are a couple of ways to attempt this:

• Keep adding features, and create truly worthwhile features that are only available to higher paid plans.
• Improve the marketing/site direction of new users, so that they are more compelled to sign up for a higher paying plan.
• Make it obvious in the application that certain features are missing from their lower paying account, without being blunt and obnoxious about it.
• Make upgrading, downgrading, and canceling as painless as possible.
• Varying levels of support.

Speaking for Wufoo, we’ve been working on these ideas for a year now, and noticed varying levels of success. The worst payoff has been premium support, but we haven’t tried throwing phone support into that package. One noted benefit of phone support is the ability to resolve an issue immediately. Adding features is definitely a plus, but nothing drastic. Actually, slow and steady seems to be the way things are, so there may be no home run solution that increases this number by 20% in one go.

Seasonal Trends

Perhaps the most demoralizing thing that can happen to a first year startup is the change in sales from month to month. The only way to get through it is to go through a year and see what happens, but try to prepare yourself for the fluctuations, and to predict what months will and will not work for you.

For most web services it will be a given that December is a horrible month comparatively. To put it into perspective, RegOnline has noticed an 18% decrease of registrations compared to the annual average, and Wufoo saw a 50% decrease. And even though the 50% figure is distorted by growth, December was still 25% lower than the prior October. A best guess prediction for the drop in sales is the trifecta of budgets running low towards the end of the year, the holiday season, and money being spent elsewhere (bonuses, travel, consumer goods).

Thank You Participants!

This article is based on the panel we presented at SXSW 2007. Many thanks goes out to hours of data collection put in by all the members: John Zeratsky (of FeedBurner), Josh Williams (of Blinksale) and William Flagg (of RegOnline). We asked a lot from them and they were generous enough to help us out and share their company’s information. You can download a copy of the graphs from the presentation’s slides here.