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!

One thing that’s really nice about working with Wufoo is that the attention to detail doesn’t stop at just our UI. Whether it’s the efficiency of a query or the tools we’ve developed for backend development and benchmarking, the team is equally fanatical about making the code on the inside as beautiful as the design on the outside. In fact, whenever one of us is creating a brand new feature or interacting with an old, inflexible piece of code, we’ll take the additional time to ensure that it’s clean and readable for any future programmers working on that code.

The thing I like about our rewrites is that the focus isn’t solely on making it work. We also always strive to make it easy to work with—basically, creating maintainable code. Now, making sure our new code is clear and easy-to-read can be a tedious process that slows down the initial pace of development. But, we’re all firm believers that while the last programmer to write a piece of code might not have known any better, it pays off when Alex, the Programmer of the Present, is nice to Future Alex, the guy that’s going to have to fix the bugs left behind.

While reading through lots of code can give you an appreciation of what well-written code looks and feels like, the ability to create it is a skill that is developed from experience and frustration. Luckily, there are a number of excellent articles and books out there to help the aspiring code perfectionist. The following resources are ones that have helped me personally strive to write code worth looking at :

Articles

• Seven Pillars of Pretty Code - Sage advice from the developers at Perforce. A great article and example giving credibility to the fact that maintainable code is essential to a software development companies bottom line.

• Code Brevity - Advice on the benefits of being succinct. Learn about the dangers of over thinking your solution and overestimating your problem.

• Style is Substance - “What benefits do we get from freedom of style that outweighs the cost we pay for it?”

Books

• “Creating Code as an Essay”, Beautiful Code - A description of the principles that guided Yukihiro Matsumoto’s goal of making Ruby a language that creates happy productive programmers.

• Domain Driven Design - Stresses the importance and benefits of clear communication in a development team’s code, design, and even speech. Describes a ubiquitous language and design as the base of a products distilled knowledge.

• Refactoring: Improving the Design of Existing  Code - A guide to improving program internals from with the wisdom of lifelong programmers’ experiences. “Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure.”

• Code Complete 2, Themes in Software Craftmanship, Chapter 34  - “Communication with other people is the motivation behind the quest for the Holy Grail of self-documenting code.”

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.”

Adobe AIR

Adobe AIR has made great strides in providing a cross-platform application architecture that sets a new benchmark for web developers dreaming about making things “better.” This environment provides a way for web developers who are comfortable developing in Flash, Flex or HTML to easily port their apps to a desktop environment. Like other frameworks that produce installable code it can install shortcuts on the desktop and interact with the file system. In the hands of someone familiar with creating Flash interfaces, AIR is capable of utilizing beautiful UIs that are not confined to the browser. AIR can also use SQLite as a database, which allows a developer to create a truly disconnected system. Additionally, using a specified coding model and an Adobe server product called LiveCycle, offline data synchronization can be handled automatically, freeing the developer the burden of writing this code alone.

One of Adobe Air’s strengths, the inclusion of an out-of-the-box synchronization, is ironically one of it’s downfalls. While this technology may save the developer loads of time, the configuration and maintenance of a J2EE-compliant server like jBoss (LiveCycle must run in a J2EE container) may prove to be overkill for a lot of organizations.

Another downside of Adobe AIR is the lack of true multi-threading. Plugins like Google Gears and Silverlight both expose multi-threading out of the box. The AIR framework, on the other hand, runs on a single thread. System threads to perform database operations are spawned separately, but once the data is returned, the processing of this data occurs on the same operating thread as the UI. While patterns exist to minimize the impact on the user, they may lack the sophistication veteran desktop programmers are used to working with in other environments.

One thing to keep in mind about developing an installable application like AIR, is the responsibilities that comes with the power of developing with AIR’s API, which is rather extensive. Just like any other application run from an installer, the user makes one choice at the beginning of the process to explicitly trust the application developer and the application. Because AIR has access to the file system, a developer with the wrong intentions could do great damage with it. While the AIR HTML security is designed to protect developers from writing applications that could be exploited by third parties, the up-front contract between the user and the AIR application still gives the developer a lot of opportunities to do evil. Check out Lucas Adamski’s article to get an understanding of the AIR security model.

Google Gears

Google Gears is a framework that adds powerful desktop functionality to the browser through a toolbar or browser plugin. Google Gears exposes three major components: LocalServer, which allows developers to cache and serve application resources (HTML, JavaScript, images, etc.) locally, Database to store data locally in a fully-searchable relational database powered by SQLite, and possibly the most important offering, the WorkerPool, which makes web applications more responsive by performing resource-intensive operations asynchronously.

From a security perspective, your users end up making a smaller commitment with Google Gears. Gears runs within the sandbox of the browser, storing data BLOBs and the SQLite DB within a protected area. Unlike an installed application, Gears does not have arbitrary access to the file system.

One promising feature in Google Gears is the BLOB API, which provides a way to reference binary data in web applications. Google’s Chris Prince explains in this video how the BLOB API can allow the developer to manipulate a memory stream that the browser can interact with to create an elegant solution for large file uploads.

Google Gears does find itself lacking in two areas: easy offline synchronization and advanced integration with the desktop. No framework is provided for synchronization like AIR. The architecture documentation explains to the developer how to check online status, but leaves the synchronization code up to the developer. Additionally, Gears is confined to the browser and so an application developer has no way to adjust the user experience outside the confines of the page. While the new Gears API has desktop shortcuts and Growl-like / Growl compatible notifications (depending on your OS), an application designer is very limited in creating the controlled experience you see in most desktop applications.

Microsoft Silverlight

Silverlight is a Rich Application Architecture designed by Microsoft meant to topple Flash as the leader in rich online content. Like Google Gears, it installs as a plugin and runs in all the major browsers. It offers slick vector graphics support, a sandboxed offline data storage component, and most importantly, access to a reduced version of the .NET runtime. Like all Microsoft development tools, the framework is steeped in Microsoft-specific buzzwords, but the concept looks compelling.

Silverlight consumes XAML documents that act as the UI layer instructing the instantiation of objects written in one of many of the languages supported by the .NET framework. This multi-language support is a key selling-point of Silverlight. It allows developers from an enterprise to contribute their pre-written libraries to a Silverlight project, provided they meet certain specs.

One major con to the development of a Silverlight project is the barrier to entry set up by the IDE. Unlike the other dev environment listed here, Microsoft stands alone in charging thousands of dollars for a single developer seat. For example, outfitting your single designer with Expression Blend, the creatives tool for working with XAML, and two of your developers with Visual Studio 2008 costs over $1700.

One other major concern is the install base and market penetration of Silverlight. Microsoft is pushing hard to power big-name events like the Demographic National Convention and the 2008 Olympics, where they reported that of the 50 million visitors nearly 50 percent of them had the Silverlight plugin installed. Compare that with the over 80 percent of browsers running Adobe’s Flash and it is easy to understand why website developers may be reluctant to serve a page that requires users to install another plugin. That said, with Silverlight 2.0 slated for a October 15th release date, you can be sure that Microsoft will be finding bigger venues to show off their shiny new plugin.

Further Reading

While this wasn’t a comprehensive review, I hope it’ll give you a nice jumping-off point for your own research. For more information, definitely check out the following articles:

• Silverlight Pros and Cons
• Adobe Air Pros and Cons
• Synchronization with LiveCycle
• Gears 0.4 Release
• Facebook uses Gears to Power Messaging

One of my favorite implementations of using programming to supplement the color picking process was done by the clever Canadians over at Dabble DB. All you have to do is upload your logo and their application will automatically pick the colors based on the information contained in the image and create a theme for their web app that will match the logo.

It’s an impressive feature that helps the user focus on getting things done rather than worry over the details. While I won’t be going into all of the ideas they used to implement their feature in this article, I do want to take some time to talk about how you can get a legible contrasting foreground color for a piece of text when given a specific background color.

When we were working on the Wufoo Form Gallery, I wanted a way to represent the pre-made color palette themes in a concise format without having to go through the laborious process of making a screenshot for each one. After a lot of trial and error, the following format is what we came up with for the gallery to represent themes:

The problem that we ran into after coming up with a structure that we liked, was that the text inside each color swatch needed to have some sort of logic applied to it so that it would show legibly regardless of whether it was a dark swatch or a light swatch behind it. This is when we turned to color theory to help us out.

According to the W3C, when you’re evaluating your web site for accessibility, you should ensure that foreground and background color combinations provide sufficient contrast when viewed by someone having color deficits or when viewed on a black and white screen. How does one know if two colors will provide sufficient contrast? Well, the W3C, being the fastidious folks that they are, provide the following definition and formulas to make what seems subjective very quantifiable:

Two colors provide good color visibility if the brightness difference and the color difference between the two colors are greater than a set range.

Color brightness is determined by the following formula:
((Red value X 299) + (Green value X 587) + (Blue value X 114)) / 1000

Color difference is determined by the following formula:
(max (Red 1, Red 2) - min (Red 1, Red 2)) + (max (Green 1, Green 2) - min (Green 1, Green 2)) + (max (Blue 1, Blue 2) - min (Blue 1, Blue 2))

Techniques For Accessibility Evaluation And Repair Tools

And so, if you’ve got two colors and their color brightness difference is greater than 125 and the color difference is greater than 500, you’re in the clear. Unfortunately, the formulas are only a starting point. They can evaluate whether your colors are made to be together, but they can’t actually decide your colors. Thankfully, the Internet is filled with a number of wonderful people that have tackled the problem head on. One of our favorite solutions we looked at was created by Patrick Fitzgerald over at BarelyFitz Designs. His CSS Color Class allows you to refer to colors using abstract names like base and highlight, automatically generate color gradients from a single base color and also adjust the contrast of foreground colors so they can be legibly seen on top of background colors.

While the CSS Colors Class is great and comes highly recommended by us (we’ve been able to do some pretty neat experimental stuff with it that we’ll hopefully use in the future), we thought for our purposes in the gallery, it was a bit too much overhead. Eventually, we ended up creating our own Smarty Modifier plugin based on code we found in the PHP documentation on the hexdec function—boy, do we love that community. Here’s the code we came up with, which can be easily be rewritten if you don’t use Smarty in your development environment.

function smarty_modifier_contrast($hexcolor, $dark = '#000000', $light = '#FFFFFF')
{
    return (hexdec($hexcolor) > 0xffffff/2) ? $dark : $light;
}

It’s very simple and very lightweight, which was exactly what we were looking for in a solution for the problem. The way the code works is that given a hex color like #FFFFFF or #CCCCCC, it will return either the hex for black or white depending on what’s appropriate. You can also pass in variables for $dark and $light in case you want the function to return colors other than black and white. In our Smarty template, we call it in our markup structure like so:

<span class="palette">
    <var class="w" style="background-color:{$bgHtmlColor};
        color:{$bgHtmlColor|contrast}">W</var>
    <var class="l" style="background-color:{$bgLogoColor};
        color:{$bgLogoColor|contrast}">L</var>
    <var class="i" style="background:{$bgInstructColor};
        color:{$ftInstructColor}">I</var>
    <var class="f" style="background:{$bgFormColor};
        color:{$ftFieldTitleColor}">F</var>
    <var class="h" style="background:{$bgHighlightColor};
        color:{$ftFieldTitleColor}">H</var>
</span>

Notice that the code doesn’t take those color difference and color brightness formulas into account. Basically, it crudely (yet kind of elegantly) divides the RGB color spectrum into two halves and if the color you give it is on one side, it returns one value, otherwise, the other. Here’s a very rough visual approximation I mocked up to illustrate the concept:

And so while it’s not perfect, in 99% of cases, the function does what you need it to do without a lot of number crunching or programming overhead. Here’s an image showing off the function in action on a number of the themes we created in the gallery.

We’ve even recently reused the functionality when we made some upgrades to our graphing system in Wufoo. Now, our graphs automatically determine and use the appropriate color for the grid lines based on the background color a user has selected from their themes.

This way, the graphs are easy to read and follow even on a dark theme palette. It’s a small detail that we think makes a lot of difference in an application. If you want perfect contrast, then obviously CSS Colors is the way to go for you, but for us we’ve been really happy with the results.

Gavan Fitzsimons and Tanya Chartrand, professors of psychology and marketing at Duke University, did some research on the topic by subliminally priming over 300 subjects with either an Apple or IBM logo. They were then given a brick and asked to come up with as many uses for the brick as they could. The results of the study revealed that brands and our environment influence our thoughts quite a bit. Apparently, the subjects exposed to the Apple logo “generated significantly more unusual uses for the brick compared with those who were primed with the IBM logo.” You can watch the researchers talk about the study in the following video:

While Fitzsimons has focused some of his conclusions toward the marketing departments behind these brands, it’s more interesting for us to know that the personality of a company can influence and filter down to users by logo alone. And so the argument can be made that purchasing tools that are aesthetically pleasing and innovatively designed by companies with similar attributes can help inspire our subconscious to also want to create aesthetically pleasing and innovative software.

Here’s some anecdotal data that will help emphasize the point. J.J. Abrams, one of the creators of Lost, gave a talk at TED about why he’s so interested in the power of mysteries. A little after the 8th minute, he presents exactly why he uses Apple’s products when he writes:

I love Apple computers. I’m obsessed. So the Apple computer. The powerbook. It challenges me. It basically says, “What are you going to write worthy of me?” I can feel this. I’m compelled. And often I’m like dude, today I’m out. I got nothing.

J.J. Abrams - Mystery Box

Chris has written about this before in an article about the role of design in businesses, but the Japanese believe that all products should strive to have this inspirational quality in their work. 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.

And if you’ve ever picked up a katana—a Japanese sword of the finest craftsmanship, then you’ll know exactly how this manifests. The thing to take away from this, of course, is not that Japanese products or Apple computers are the only things to use if you’re going to be innovative. It’s that context and environment matters in ways that people sometimes don’t even realize. Because humans are relationship-making creatures, we are emotionally influenced by the things we encounter over and over again and tools obviously fall into that category. And so, maybe, the choices we make regarding our tools shouldn’t come down to price alone. And maybe, as the developers of tools, we should strive to make products that inspire others with equal passion and energy.

The Benchmarks

Basically, we set up a simple PHP page to iterate over a loop and create 1) a giant concatenated string, 2) an array of arrays containing the word ‘test’, and 3) an array of objects with one variable set to ‘test’.

As the table shows, creating objects takes a good amount of memory and time when compared to a string or array. And since 7.7mb is nearing the default memory limit for PHP, the page is about to time out. Sure, the memory limit can be increased, but the point is that there is still a maximum. For most pages, 11,000 objects is overkill. But in some cases, like exporting a hefty database to CSV format or returning data from a public API, we may want to return 50,000+ records.

Workarounds

The good news is that the memory limitation does not put us in a place where the advantages of reusable code is completely removed. We just have to take a few precautions when writing code that has intensive looping or object creation.

• unset() - Avoid getting at objects through the accessor, and work directly with the recordset loop. After each iteration, unset the object that was just created. After a quick test, 45,000 objects could be created and unset using 1.43mb of memory at peak.

• Static Method Calls - A static method can be called without the need to instantiate an object. For example, if our desired output is an XML string, but we need some of the objects helper functions, we can still call functions off of the objects statically with Object::function(). Doing so only increased memory usage from 1.45mb to 1.46mb in the string example.

• Paging - The downside to unset() and static methods is that we have to bypass our accessors to get at the objects and work directly with the loop. A third option is to be strict with paging, and never allow for more than X number of objects to be returned. This will keep the code 100% consistent, but may be a bit more intensive on the database and increase page execution time.

Why Does this Matter?

Many development techniques, such as domain driven design, keep a set of value objects along with an accessor to each of those objects. The accessors act as an API that make retrieval of the objects easy and consistent. For example, let’s say we have a User object, and a UserAccessor — we would call UserAccessor->loadAllUsers(), which would return to us an array of User objects. Then, we can loop through the array, and display a list of all users and have access to the member variables and functions.

This is great because all developers work with the same objects, and SQL queries are constrained to accessors. Even if this isn’t your preferred development style, chances are your object oriented approach strives to achieve similar levels of consistency. That said, we can see from the benchmarks above that there may be situations where a portion of code we’ve created cannot return an array of objects because of memory limitations. Overall, object memory usage is far from a deal breaker, but it is something every developer worried about scaling should be aware of.

For more information, here are a couple of links that may provide some more insight.

• Practical and impractical PHP Optimizations

• 40 Tips for optimizing PHP

• Use Profiling to Determine Bottlenecks

The problem is once you’ve amassed this collective list of wishes, hopes and desires, you realize that your limited resources (time, money, manpower) force you to have to prioritize them. You can only do so much right now, implement certain things eventually and pretty much make everything else wait. If you’re not careful about managing your expectations and your users’ expectations, it can end up feeling like a game of constant disappointment because the things you want to do will always be larger than what you’ve already done.

Since prioritization is really about ranking items, democratizing the process through voting is one way to go about it. In fact, community link ranking sites like Reddit.com end up having the features basically voted on and delivered to them by fiat via the very service they created. Feature requests from the community often rise up on the homepage at Reddit demanding the founders to do something about it. And often, if not every time, the founders have responded accordingly. I imagine there’s a mixed sense of excitement and annoyance that comes from developing by public decree, but it ends up being an amazing experience for the users. Nothing seems to deepen a relationship more than seeing that there’s an actual relationship between what you ask for and what gets done.

In fact, if you want to outsource prioritization to your users in a similar fashion, you can even use a service like UserVoice to make your community part of the feature request discussion. Once submitted, ideas can be voted up or down (just like Digg or Reddit) and the status of the feature requests can even be updated by you, which creates a nice feedback loop of what’s being done.

Now, there’s definitely some drawbacks to having the development schedule of your product come solely from the masses. One of the biggest is that your users, for the most part, ask for Frankenstein. If the road to hell is paved with good intentions, then the road to feature bloat is probably paved by agile developers always listening to their users. Henry Ford probably has the best quote on the topic:

“If I had asked my customers what they wanted, they would have said a faster horse.”

In fact, Jakob Nielsen even argues that listening to your users actually breaks the First Rule of Usability:

To discover which designs work best, watch users as they attempt to perform tasks with the user interface. This method is so simple that many people overlook it, assuming that there must be something more to usability testing…ultimately, the way to get user data boils down to the basic rules of usability:

• Watch what people actually do.
• Do not believe what people say they do.
• Definitely don’t believe what people predict they may do in the future.

For additional perspective, Jeff Atwood over at Coding Horror wrote an excellent essay titled Don’t Ask — Observe, which highlights why especially in web applications, we should have no excuses about getting down to the bottom of our users’ behavior.

Why ask users if they’d like recommendations in their shopping carts when you can simply deploy the feature to half your users, then observe what happens? Web sites are particularly amenable to this kind of observational testing, because it’s easy to collect the user action data on the server as a series of HTTP requests.

For those of you thinking that data driven development requires a complex system of monitoring and analytics, you’ll be surprised to know that you can even do it with something as simple as a 404 error. Tech-savvy members of the web community know that a 404 error is likely the fault of the web developer. However, Stephen Kaufer of TripAdvisor.com wagers that when your Mom surfs the internet and encounters one, she just assumes (without assigning blame) that ‘something went wrong’, presses the back button, and chooses another link. And so before deciding to spend engineering resources to develop costly features on TripAdvisor, he would often determine whether something would have a strong uptake by creating a fake button or interface element of the feature on the site and have it lead to a 404 page he monitored. He’d then publish the link on a subset of his web servers for a statistically relevant period of time and count the number of click-troughs. If the count for the link is high, he’ll task his developers with the creation of the actual feature. If not, he’ll direct his staff to create something else. It was simple, saved him lots of money and only cost him some slightly confused users.

That being said, showing 404 errors on purpose isn’t for everyone. If you don’t have the stomach to treat your users as unwitting participants in a web development experiment then the 404 Test might not be for you. Thanks to the folks at Clearleft you can take a more intimate approach to user observation by taking it to the streets with a laptop and Silverback, their application for implementing guerrilla usability testing. After recording a session with a user, you can playback a screecast of what they were doing along with video of the user in action while they use your web site or software. It’s a brilliantly elegant piece of software that gets the job done without breaking the bank.

Additional Reading

• How To Outsource Product Management to Customers

• Prioritizing Features does not equal Product Management

• Are You This Agile? Paul Graham Changes Hacker News While You Wait

• Wikipedia Article on Software Bloat

The Problems with 5 Day Workweeks

A 5 day workweek is pretty standard in corporate America and it’s what we started with first. Each day basically consisted of 8 hours of non-structured programming and product development. One thing we noticed right away was just how many highly counterproductive interruptions occur at seemingly random times throughout the day. Interruptions ranged from important topics like company strategy and budget allocation to “inefficient” topics like interesting blog posts, hypothetical questions about potential products, and talking about politics or fantasy football. We were always able to accomplish a satisfactory amount of work during a 5 day workweek, but we definitely didn’t feel like we got the most bang for our buck. This is because while we were happy with our output, the 2 day weekends didn’t seem to recharge our batteries. After stretching ourselves to crank out code around those interruptions for 5 days straight, we ended up feeling like a weekend just wasn’t enough of a respite to keep the work from feeling like your typical grind.

The Problems with 4 Day Workweeks

Because we were excited about the prospects of longer weekends and more efficiency, we thought that the much hyped 4 day workweek would be our saving grace. The 4 day workweek that we tried out operates under the assumption that you can accomplish just as much in an efficient 4 day workweek as you would in a typically inefficient 5 day workweek. Basically, because you know there’s only 4 days to get things done, you optimize your time to make those 4 days count. The extra buffer of a 3 day weekend also helps you to hit the ground running on the next cycle. Unfortunately, there were two major problems we ran into when we tried it.

The first was that a 4 day workweek just wasn’t as productive as a 5 day workweek. It wasn’t because of efficiency. We did become more efficient with our time, but 3.5 days of productivity during a 4 day workweek is still less than 4 days of productivity in an inefficient 5 day workweek. The reason it’s 3.5 instead of 4 is because you can never really eliminate every distraction, meeting and task that comes up in your typical business setting.

The other problem was that a 4 day workweek consisting of only programming and the critical meetings needed to get things done left something missing from our company’s culture. Even though discussions about the newest programming toys, the hypothetical strategies, and the fantasy football smack talk may not be efficient, we operate a lot like a think tank. Some of our best ideas have spawned from shooting the shit, and even if our wandering thoughts didn’t always lead to something measurably productive, they have been crucial to us innovating and bonding as a group, which we think ultimately leads to increased morale and even productivity.

Our Solution - The 4 1/2 Day Workweek

While the 4 and 5 day workweeks weren’t perfect for us, they did give us some important clues as to what we wanted in our ideal workweek. Our recipe for the optimal workweek called for 4 solid days of product development, 3 days of mental rest, and plenty of time to discuss whatever may be on our wandering minds, whether it be work related or completely random. And what we came up with is the following schedule:

Monday - Thursday

Mondays through Thursdays are dedicated to product development and only product development. There are no exceptions. We aim to accomplish as much in these four days as we would have in the traditional 5 day week, and since every one of us has to work hard to meet our goals, what ends up happening is that if something comes up that isn’t on our weekly list of items to accomplish or is controversial in nature, it must wait. If you want to argue about why X feature is absolutely necessary, or debate whether or not Safari or Firefox is the better browser, or kick around ideas for the company trip, it has to wait till Friday. Sometimes a person can accomplish their goals by working 6 hours a day, and sometimes it can take 10 or more hours a day. That’s up to them. And while it can get pretty intense around here and easily leave you wiped out come Thursday night, it’s all good because you know there are 3 days of mental rest right around the corner.

1/2 of Friday

Fridays are for resting the analytical parts of our brains, discussing business topics, and engaging in the activities that we find are crucial to the overall health of our company—like bonding and customer appreciation. Our typical Fridays start at about 2:00 PM, which gives everyone time to sleep in, relax a bit and if they want, get some additional work done. Then we’ll meet up at a team member’s home (we rotate every week) to accomplish most, if not all of the following activities:

• Bonding - We’re passionate about what we do, and since we’re 6 people with 6 different personalities, that passion can easily lead to arguments. We’ve never shied away from a heated debate and have always encouraged lively discussions, but we’ve always kept it from getting personal. At the end of the day, we all have to get along and work together and so any lingering tensions must be addressed and ironed out during this period. In order to make sure nobody takes things too seriously, we use Fridays to bring us closer together by watching movies, going out to dinner, talking about our personal goals, discussing the newest technologies, and just having a good time.

• Discussing Company Business Face to Face - Since 93% of communication may not be verbal, we find meeting face to face a worthwhile exercise when dealing with business matters and decisions. This will include what we’ve accomplished for the week, budgeting, overall health of the company, new features, and other specifics to the company that need to be discussed on a regular basis.

• Thanking our Customers - There are only two immovable rules we have for every employee in our company. Everyone does customer support and everyone must take time to thank the people that pays their paycheck. After discussing business, we’ll pop in a classic movie like Point Break and take a couple hours to write our customers hand-written thank you cards to show them how much we appreciate them. We’re able to accomplish about 10 cards per person, and even though this small gesture may not make a measurable impact on the bottom line, we believe it definitely adds value to our corporate culture by reminding everyone of our place and purpose in the long run.

• Meeting People - As a business begins to grow, it’s only natural that people from other businesses are going to want to meet you. Sometimes they just want to meet other local entrepreneurs, and other times they want to talk about business development related items like product integration. Driving, eating, and talking require a good chunk of time, and since this time would interfere with our 4 day productivity goals, we’ve designated Fridays as the day we meet with people and representatives from other companies.

• Give Back - We actually just started kicking around this idea, but we’re hoping to also use our Fridays to give back to the community that hosts our startup. Whether it be Habitat for Humanity or a local food drive, we think good corporate citizenship is an important part of running a happy business. We also think that it’ll be great at boosting morale and fostering additional bonding.

Conclusion

Now that our work is broken up into the two distinct areas: product development and “other stuff”, we think we have a pretty good framework that helps us decide when to focus on what. We’ve been able to meet our productivity goals, enjoy the benefits of a 3 day weekend, and still make time for the tedious and inefficient parts of our business. Of course, this structure works well for us because we love what we do and also who we work with. It’s natural for us. I don’t think you can force every company into this schedule because it’ll end up being a lame “Fun Friday.” You probably won’t end up with an open dialogue and sometimes people would rather just work than spend time pretending to get along with their co-workers. I’m not entirely sure how this will play out as we continue to grow and scale our company, but it’s definitely clear that a company works best when it’s employees are genuinely focused, well rested, and enjoying life.

Karakoram is just the name of my hard drive (a reference you’ll know if you’re a Genghis Khan fan). Then there’s two Textmate projects, one for the Subversion checkout of Wufoo’s source code and the other for our recently released desktop notifier, Unplugged. The three folders, Infinity Box, Code and Progress are used for quick triage.

• Infinity Box is for all company related matters.

• Code is where I keep all the cool scripts, code projects, snippets and examples I come across when I do research on any number of ideas.

• Progress is my writing dump folder. It’s filled with hundreds of text files containing unfinished ideas, outlines, future blog posts, Particletree features, poems, short stories and even recipes. Basically, if started writing something and I didn’t finish it, it goes in that folder.

About once a week, the root of the Infinity Box folder gets additional triage treatment. Files I’ve dragged in there will go into the following structures:

Everything I’m responsible for in regards to Wufoo fits into the categories shown in the secondary folders. I highlighted the Icons, Images, PSD and Screenshots folders because I use them the most and got tired of having to scan to find them (milliseconds, I’ve found, are precious when you’re looking at something hundreds of times a day). Here’s a quick rundown of those folders :

• Documents : These are company documents like invoice templates, stationary, employee handbooks, etc.

• Flash : Leftover from when Wufoo had a lot more Flash in the interface than it does now.

• Fonts : A copy of the fonts used around the web site and in the marketing materials for Particletree, Wufoo and Treehouse. In Wufoo, we use the always excellent Whitney and a customized version of Milkman.

• Icons : A copy and reference for all the icons and avatars used in Wufoo.

• Images : This contains a copy of any stock photos we might have bought for artwork and any finished renderings from PSD files.

• Inspiration : As I browse the web and go through my feedreader, I use a screen capture tool like Snapz Pro X to capture anything that tickles my fancy. Lots of interface fragments, color schemes, copy I think is brilliant and even videos of interactions. Whenever I get stuck on a design, this is the folder that helps me the most.

• Legal : Corporate documents, contracts and investment papers.

• Marketing : Anything used to help someone spread the word about Wufoo. Copies of all the advertisements I’ve designed, logo kits, custom made icons and badges, etc.

• Movies : Screencasts used in our documentation and demos.

• Photos : This one is for documenting the history of the company. Photographs of the team in action, group photos, company trips, etc. A copy of almost all of these are on our Wufoo Flickr account.

• Press : Safari webarchives, screenshots and copies of articles and interviews written about Wufoo, Particletree and Treehouse.

• PSD : Sweet photoshop files. This is the folder that is constantly backed up in multiple places and bunkers.

• Screenshots : These are of the application and the web sites. Again, most of these images are also uploaded to the Wufoo Flickr account for posterity.

• Wireframes : XHTML, CSS and a little bit of JavaScript that’s in progress. These are usually experimental redesigns, Particletree proof-of-concepts and fragments of HTML markup ideas.

And that’s a quick snapshot of my organizational foundation. A lot of this is leftover from habits made while keeping design and writing notebooks in college. It’s tremendously useful when I’m working and when I need some inspiration to get out of a rut. What I really love about the system is how it automatically helps me document and track the history of our application interface and our company’s decisions. Lately, I’ve started to see that knowing how I got to a place is sometimes just as important as where I want to go.

If you have an interesting work layout for your files, I’d love to hear about them. Just write about it on your blog (with screenshots too if you can!) and link to them in the comments.