A Better VOIP Client

I dislike phones. Not so much the phones themselves, but their interface. The basic interface, a bunch of numbers and some special keys, is bad enough, but when this interface is extended it's always a mess. I don't think I've ever seen two phones with the same mechanism for programming the speed dial buttons and the conferencing features are always hopelessly arcane. Even something as simple as putting someone on/off hold can be ridiculously complicated.

This is one of the reasons I prefer VOIP service to POTS service. I use a service called MyPhoneCompany.com (bad marketing - reasonable service) because they allow me to pay minimal $ for "softphone only" plan. Not having to have a clunky piece of legacy, single-purpose audio signaling technology taking up space on my already overcrowded desk is a big plus for me. Wherever my laptop goes so does my "phone", which is perfect because I seldom call people unless I'm using my laptop and, if I weren't, I'd be using my cell phone.

But there's a problem to all this. For reasons that I can't comprehend, most VOIP clients go to great pains to try and look like physical phones. The number buttons are the primary interface element and the mute, conference, etc. elements look like the kind of tiny buttons you see on a cell phone. Meanwhile the crucial features like contacts and call history are buried beneath layers of menus. This is just stupid and misguided (I know that Skype, Yahoo, and other IM clients that provide voice service are an exception, but I'm talking primarily about SIP clients here). I want a VOIP client that exploits the fact that it is a computer application with access to all the GUI wizardry provided by a modern OS.

Here's what a VOIP client should look like (it's also what an IM client should look like, but let's not go there):

1.) It should integrate with my contacts database (whether that is Outlook, Thunderbird, Palm Desktop, whatever) so completely that it should almost seem like an extension of that system. I don't ever want to enter names and phone numbers into the VOIP application and have them stranded there. It would even be okay if the VOIP app didn't allow me to enter contact information, but instead forced me to use my PIM client (though it would be nice to, on those occasions when I manually dial a number, to easily record that number into my contacts).

2.) You need to be able to access "the number buttons", but they are not the most important element of the interface. A numeric keypad should be off to the side and out of the way. Handy when you need it, but not taking up too much space or attention.

3.) The most important element of the phone is my contacts. I want to see my contacts as a "tag cloud". The tags are placed on individual phone numbers but the phone numbers should have meaningful names like "Smith, Bob (home)" (the same way del.icio.us *tags* URLs but what you *see* is the "site name" or whatever label you have slapped on the entry). Clicking on a tag brings up a list of all the entries labeled with that tag. Clicking on an entry dials the number for that entry. Simple, right?

4.) I want the tags to be partially managed by me and partially managed by the VOIP app. For example, there should be an app-managed tag named "mostCalled". This should contain the 10 or so contacts that I call the most often as tracked by the app. Other automatic tags would be the letters a-z correlated against first letter of the persons last name or the name of the company, etc. For example, clicking on the "a" tag would show me a list of entries like "Adams, Michael (home)", "Adams, Michael (cell)", "American Airlines", etc. There could be other app-managed tags that might be useful like "recentCalls", but you get the idea. The other tags should be managed by me pretty much the same way I manage tags for del.icio.us.

5.) Obviously I should be able to search my contacts. The contacts/VOIP integration should include launching the VOIP app when I click on a phone number in the PIM app.

6.) Conferencing in another number to an existing call should be implemented with a context menu selection off an that entry; find an entry, bring up the context menu, select "conference" and they're called and added.

7.) All other features and functions (hold, mute, record, etc.) should be implemented the way you would any normal, modern GUI (menus, toolbars, ribbons, etc.)

If anyone implements something like this, please let me know and I'll help test it.

Two Forward and One Back

Got to see a demonstration of Salesforce.com's Appex platform and the AppExchange marketplace at SaasCon. I was very impressed by the demonstration. It's difficult to convey the visceral impact of seeing the cycle of idea->development->advertisement ->installation->evaluation->purchase taking place without either the developer or the customer having to install or manage anything. I caught a glimpse into one of software's possible futures. When all was said and done, though, I had to remind myself what I was really looking at; an application coded in a proprietary language running on a proprietary platform.

Obviously I have no knowledge of Salesforce's plans for Appex and AppExchange, but what I have seen leads me to believe that they have no intention of opening up the system to competition. Sure, sure, anybody can write apps on Appex and anybody can buy these apps. You don't even have to subscribe to the core CRM product anymore, but it's still a closed system. Appex and AppExchange are a big tent in which all sorts of interesting things can take place but, to get into that tent, you have to pay Salesforce for a ticket.

If you've been in the software industry as long as I have, you know where this is going. Neither Salesforce nor any other company is ever going to be big enough or good enough to contain the entire SaaS market. Already there exist SaaS platforms that are somewhat similar to Appex. These and others not yet built will grow in scope and sophistication to compete with Appex . The bigger more successful on-demand ISVs are going to find themselves writing and maintaining multiple versions of their applications for these various platforms. They are not going to like this (multi-platform support is a costly activity that provides no business value to the customer). Eventually there will be some sort of open SaaS platform in which the APIs, management touch-points, deployment model, etc. will be "standardized" (not necessarily by a standards org) and the platform operators will compete on price and service quality (reliability, scalability, etc.). Salesforce and the other proprietary SaaS platform players are either going to have to switch to this open platform or fight an increasingly difficult battle to keep their ISVs and customers locked in.

I'm an idealist so, of course, I'm bound to ask "couldn't we save ourselves the pain and go straight to an open platform?" Obviously it's in Salesforce's short-term interest to lock the ISVs into their language and platform; it's basically a license to print money. But in the long term, when the switch to open SaaS platforms occurs, they will have only hurt themselves. The history of the computer industry is full of companies that got so fat and sloppy on their proprietary systems they were unable to compete when the next wave removed their ability to keep their customers captive.

It seems counter-intuitive, but I think Salesforce's best long-term move is to open up the Appex platform to competing service providers. That way the de-facto, open SaaS platform is Appex, a platform in which they (obviously) have a huge lead. The similarities to Java are obvious but, to be fair, I don't think Sun stood as much to gain from holding onto Java as Salesforce does from holding onto Appex.