When More is Less

I've been using OS X Lion, the new Apple Mac operating system for a couple of days and I have relearned an important lesson about application design: when designing applications, more is often less.

Overall I have found the refinements in the OS X Lion user experience delightful. The new mission control, dashboard and trackpad swipe features are magic. Spotlight, the OS X search capability, seems fast and more accurate; I think full screen iPhoto is wonderful. I look forward to learning more about versions. In all of these areas of improvement, Apple has refined the user experience while leaving the core feature set basically the same: Spotlight is still a search utility, iPhoto hasn’t changed and the Spaces ability to utilize multiple virtual screens has been vastly simplified with the new swipe capabilities.

Unfortunately, in one area I believe they reached a bit too far, added too many features and made the user experience too complex. For the past couple of months I have been using the Sparrow email client. On the company's web site at www.sparrowmailapp.com they state "Sparrow is a minimalist mail application designed to keep things simple and efficient." I find Sparrow the fastest and most efficient way to manage my multiple email accounts on my MacBook Pro. With Sparrow's “minimalist” approach there are times I wish for an additional feature, however since my productivity is so much greater with Sparrow I stick with it.

Then three days ago, after installing OS X Lion, I gave mail.app, the built-in OS X email client another try. Many of the "industry experts" raved about the enhancements to mail. Here is what I found: Mail.app is a feature-rich email environment with full support for threaded conversations, an iPad style user interface and improved search. While this is all very nice, Sparrow is still more effective for me. Let me explain.

I use multiple Gmail accounts and an Apple me.com account for my email. Mail.app maps each Gmail label to a folder. When I want to move an email from the inbox to a folder in mail.app the move command lists all of my folders for all of my accounts. While this is extremely powerful—allowing users to move a message from one account into any folder on any other account—I have a lot of folders, and for my purposes, rarely need to cross-file emails. The unintended side effect is that it is very hard to find the correct folder when the move command displays a list of all of my folders across all email accounts.

Sparrow on the other hand takes a different approach. First and possibly most important, it is more well-integrated with Gmail in that it understands that Gmail labels are not just folders. When I am reading a message, from the unified inbox, it gives me the option to either label a message, or label and archive a message. The labels presented are the labels local to the specific Gmail account. Sparrow’s approach is more limited than mail.app’s, but this is in fact exactly what I want to do 99 percent of the time. It makes the task of labeling and archiving an email much easier.

In a second example, Sparrow has a wonderful “quick reply” feature. When using quick reply instead of opening a new message window Sparrow scrolls the message down and presents a small entry panel at the top of the current message. This panel does not include address information or signatures, just a place to write a short reply. The feature makes a quick reply feel similar to replying to a text message. If you need access to headers and signatures with one click the quick reply opens into a traditional reply window.

It makes sense that Apple would want to improve their mail client or introduce one that is more dynamic and feature-rich. Simplicity and ease-of-use, however, is what attracts people to their products. If anything gets added to a product, it should be value; if anything gets removed, it should be complexity. At the end of the day, in this case as in many others, more is often less.

 


The Three Hats of VoIP

Over the past few years new VoIP products and services seem like they are announced daily. While this rate of innovation is exciting, it is also very confusing. How are these companies the same or different? What service should I use for my business?

These new VoIP solutions fall into one of three general categories: hosted PBX solutions, telephone API platforms or telephone applications.

Many hosted PBX solutions, such as Packet 8, Vonage or Fonality, replace your business’s premised based telephone with new SIP phones or “soft-phones” connected over the Internet to a hosted PBX system. These solutions often result in lower costs with no premise based telephone system to support and maintain. But, there are hidden costs in this model that complicate the buying decision. The best solutions require your company to install a dedicated, VoIP-optimized Internet connection. These connections are often more expensive than dedicated phone lines so some of the costs savings disappear. Since cost is most often the driver for the switch from plain old telephone lines (POTs) to hosted PBX solutions, this space has been commoditized and has become highly price competitive. This price competition is good news for your business but creates challenges for the hosted PBX companies.

Telephone APIs from companies such as Twilio and Voxeo, offer a platform where your software developer initiates and controls phone calls without purchasing equipment or telephone connectivity. The best APIs, such as Tropo from Voxeo, give your company access to a sophisticated, and highly reliable, telephony network suitable for developing complex telephone applications. Ease of use is often a selling point of these platforms, but in reality they are only easy to use for experienced software developers since they provide infrastructure and not packaged solutions. An experienced software developer may be able to code a simple phone call with just a few minutes of work using a telephone API. But building a robust, reliable telephone solution, such as dynamic call tracking, a virtual call center, or customer notifications service with retry logic and automated scheduling, requires hundreds or even thousands of hours of work. Telephone API solutions are best for companies where integration of telephone services is a core competency and where dedicated software developers are available for application support and maintenance.

Telephone application services are completely different from both hosted PBX solutions and telephone APIs. Telephone applications, from companies like Ifbyphone, provide your business with complete, ready-to-run, hosted applications that work with any telephone - business, home, VoIP or PSTN. The plug and play nature of telephone application services enable your business to measure value immediately - increased sales, reduced service delivery costs and improved customer retention. You can use these applications to manage, measure and automate phone calls that track advertising campaigns, dynamically route calls, provide customer notifications and deliver customer fulfillment or support via virtual call centers or distributed call groups. Then by utilizing an API on top of these applications your company can quickly and cost effectively integrate these ready to run applications with key business processes.

To further clarify the differences among these three VoIP models, let’s compare them to traditional web business services.

  • Hosted PBX solutions are like Internet backup services such as SugarSync or Mozy. Instead of purchasing and maintaining your own computer backup equipment, you back up your computers over the Internet to a centralized service. While you share a high-quality backup facility, you still carry the cost of the Internet connection and the desktop computers.
  • Telephone API platforms are like web hosting companies such as GoDaddy or Rackspace. The hosting company provides you a platform to build anything you want providing you have the right skills and the staff to support your custom application.
  • Telephone application services are like Salesforce.com or NetSuite. While you could build your own CRM system, most businesses choose to use an off-the-shelf CRM solution. Salesforce.com then provides APIs for integrating with their applications and a specialized environment for extending the platform (force.com). Similarly, Ifbyphone offers an API for integrating with our applications.

While hosted PBX solutions, telephone APIs and telephone applications may share the VoIP “cloud”, these three solutions are very different. Think of hosted PBXs as replacements for existing telephone systems. Telephone API platforms provide a greenfield environment for software developers. And, telephone application companies, such as Ifbyphone, provide ready to use applications for businesses looking to increase sales, improve customer retention and increase business efficiency.

By focusing on ready to run telephone applications Ifbyphone is helping thousands of company manage, measure and automate voice interaction with hundreds of thousands of customers daily.


eComm 2009 Ifbyphone iPhone Mashup Tutorial

I recently led a session at eComm 2009 on how to build an Ifbyphone-to-iPhone App. We've uploaded the session to YouTube. You can find it on the Ifbyphone YouTube Channel, and I've also listed the URLs for the 7 parts below:

Part 1: Introduction to iPhone Applications

click here to play video

Part 2: Introduction to the Ifbyphone API

click here to play video

Part 3: Getting Started as an Ifbyphone Developer

click here to play video

Part 4: Building Your First SurVo (IVR Voice Dialog)

click here to play video

Part 5: Building Your First iPhone Application

click here to play video

Part 6: Building the PHP Middleware (Glue)

click here to play video

Part 7:  API Review and Course Wrap Up

click here to play video

You can find more information on http://www.phonemashup.com or in the developer section of the Ifbyphone website.


It's the applications, stupid or what telco can learn from Salesforce.com

It seems that a popular business model today is to deploy some telephone softswitches or Asterisk servers into a data center, contract for call termination services, and anounce that you are in the telephone API business.  Unfortunately this business approach ignores the lessons learned by following the grand daddy of cloud computing, Salesforce.com.

Salesforce.com was founded in 1999 to provide customer relationship management solutions to small and medium sized businesses.  Four years later, in 2003, after acquiring over 8,000 customers and 127,000 subscribers they released the Salesforce.com API.  Why did Salesforce.com wait so long to release an API?

It's the applications, stupid! 

Businesses buy applications, not APIs.  By allowing others to create applications for Salesforce that solve real business problems, Saleforce.com created a sustainable and profitable ecosystem.

At Ifbyphone we are following a similar process. In September of 2007 we released our current suite of automated telephone applications.  These applications enhance business processes that depend on a telephone.  Our off-the-shelf applications range from a simple virtual receptionist, voice mailbox or parallel "Find me" (think Google Voice) to sophisticated, interactive, voice-response applications such as Store Locator, Voice Broadcast and API-driven conference calls.  Any of over a dozen Ifbyphone applications may be invoked from an API call, an inbound telephone call, a scheduled outbound call, or an on-demand outbound call.

While those developers who prefer to build applications from scratch have complete access to basic call control services, the majority of Ifbyphone development partners utilize our off-the-shelf telephone applications to save time and reduce complexity.  Our customers and partners are free from the burdens of building standard call processing components such as find me, voice mail or caller ID routing.  Instead they utilize the Ifbyphone API to integrate their business processes with the Ifbyphone standard applications. 

This model works.  Ifbyphone has over 10,000 customers and has been generating revenues for over 20 months.  You can learn more about our development programs at the Ifbyphone Developers page.


What is a Phone Mashup?

Every minute of every day, somewhere, someone is pounding on their keyboard, or screaming at their computer, "How do I contact the people behind this web site, or this blog?" Too many web sites make it difficult for viewers to connect.

Later that same day you might become frustrated because the emails you sent to a business associate or friend landed in the black hole of a SPAM folder. Or maybe you were away from your computer and the screen on your phone is just too small to read, but you need to check on the delivery of the sofa you just ordered. If you call the sofa company they will put you on hold, forever. You just want to know the date of the delivery - why should this be so hard?

All of these examples are easily solved by better utilizing the everyday, plain old telephone. Telephones are everywhere today, at home, at work, in our pockets. Phone mashups combine the intimacy of the telephone with the efficiency of the web. In the examples above, you could provide a web site visitor with a Click-to-Call that connects the viewer's telephone to your telephone. You could use an automated Voice Broadcast to send messages to your customers. With an Interactive Voice Response system, the sofa company could provide you with instant customer service while saving on staff and reducing costs.So why doesn't every small business, web site creator, or blog author integrate their web world with their viewers' telephones?

While the VoiceXML and CCXML standards have driven down the cost of custom IVR, these solutions are still too complex and expensive for many independent developers and small businesses. Many Click-to-Call solutions now available in the marketplace tend to be limited in flexibility. Phone mashups require flexibility.Phone mashup APIs need to be usable by any web developer with basic web form coding skills. In essence, the phone mashup API should replace web forms with voice forms.Ifbyphone provides a very flexible family of APIs (we call them Ifbyphone Glue) that includes the ability to:

  • Initiate a traditional Click-to-Call between two parties
  • Initiate a Click-to-Virtual Receptionist
  • Initiate a Click-to-VoiceMail
  • Initiate a Click-to a full featured interactive voice response system
  • Initiate a Click-to a Find Me with full recording capabilities

Ifbyphone APIs also support the scheduling of voice broadcast messages, reminder calls, and wake up calls.In addition to initiating telephone connections from a web site, the communications facilitated by the Ifbyphone hosted platform may be activated from a telephone call. When someone calls into an Ifbyphone provisioned telephone number their call can be:

  • Routed based on the caller ANI (caller ID)
  • Routed based on the time of day and day of week
  • Routed to a voice mail account
  • Routed to a find me
  • Routed to a virtual receptionist
  • Routed to an interactive voice response application (IVR)

Ifbyphone IVR applications can be thought of as voice forms. If you know how to build a web site that uses a form to collect information, processes the information, and then displays another form, you know how to build a phone mashup.

SurVo Voice Forms** are created at the Ifbyphone web site and then invoked by an API or telephone call. A voice form consists of prerecorded or text-to-speech prompts and questions that are played for a caller, and then allows their responses to be recorded or converted into text.

When the caller reaches the end of a voice form, the Ifbyphone platform passes control to a web page you create. This web page can be hosted on any server, coded in any language and secured or unsecured. Your web page will receive the data collected via the telephone dialog (voice form) as a post or get in the same way you would collect information from an HTML form.

Once you have the data you can write it to a database, use it to query another web source, or process it in just the same way you would process information collected from any other form. After processing, your web page outputs an XML file which tells the Ifbyphone platform what to do next. The next step can be another voice form, a find me, a virtual receptionist or even to just hang up the telephone. Data provided by your web page can be read to the caller or can be used to determine the next set of questions asked.

There is no limit to the number of voice forms or the number of transitions between your web pages and the Ifbyphone infrastructure.

To summarize, the Ifbyphone Glue (API) supports the combination of information accessible from the web for presentation via voice on any telephone. All Ifbyphone services use real telephones and do not rely on desktop computer based VOIP services.

To learn more just take a look at the Ifbyphone Glue (API) documentation.

Ifbyphone Glue (API) Documentation

All Ifbyphone Documentation

**The name SurVo comes from the fact that initially this technology was built for creating customer surveys.