Occasionally I get to try something that sounds really good, but it falls on the execution because of the small details. Let us take FireFox Prism as an example. The idea is good, I get a separate fire fox window just for gmail, or other always on apps. Note that I am using it as an example only, because I just run into it. Prism is still in beta, so it is just an example.

This means that if the browser crash I don't lose my unsaved email, and more importantly, I can close FireFox (and thus release the memory) without closing my mail.

Here is why I wouldn't be using it for now:

Can you spot the difference between the two images?

The Prism one is on the left, FireFox is on the right. The Gmail on Prism doesn't display a caret symbol in Gmail's rich edit box. That is a deal breaker for me, because I can't really type without it.

I. Can't. Type. Without. The. Caret. Period.

The point that I am trying to make is that you need to consider the deal breakers for the user. And even something as small as the caret is a deal breaker.

In my last project, the first release was completely useless to some of the users, because a select list didn't contains all the old values, and we couldn't bring those values, because their presence depended on so many other things. Those users had to wait for the second release to use the application.

Deal breakers are the other side of the killer features, and are just as important when you analyze a solution. Examples of deal breakers in typical software include:

• Not supporting the old application's keyboard shortcuts
• Web application replacing local app - latency
• Different fonts (True story!  Priority 0 bug!)
• Compatibilities