VoiceXML and the ASP.Net Developer
This is a first in a series of blogs where I will explore using new Microsoft .Net technologies to develop voice/speech applications that will run on any IVR platform that supports VoiceXML. In this initial blog I will take a brief look at the history of voice application development and why I think this is a viable and productive method for developing voice applications. I will also introduce you to the specific technologies I plan on using.
I have been developing voice/speech applications for over 20 years and a lot has changed over these years. The biggest change was from developing in proprietary development environments supplied by each IVR vendor to IVR platforms that supported open standards like VoiceXML and CCXML that were controlled by the World Wide Web Consortium (W3C). These open standards radically changed how voice application were developed, moving to more web-centric tools and promises of making every web developer a voice application developer. Well almost. It made the transition easier in that the developer could still leverage there skills in areas like JavaScript, XML, web servers, and other web development technologies. But they still needed to learn voice user interface (VUI) design, grammar development, and of course this new language called VoiceXML.
The industry embraced these open standards, partially because their customer base demanded it. Customers saw the benefit of open standards that promised to allow them to develop a voice application once and it could be moved to any platform. Prior to this customers were usually locked in to an IVR platform because moving to another platform required rewriting the whole application on the new vendors tools. This was expensive because often the application development cost would come close to or exceed the equipment cost.
Then came along the tool vendors promising to make it easier to develop voice applications in this new paradigm. These vendors promised productivity gains while allowing you to develop the application once and it would run on any IVR platform. I have tried many of these tools and in reality I did not see the productivity gains that were promised and it was a steep learning curve to do much of anything with these tools. Now instead of being locked in with an IVR platform vendor you were now locked in with a tool vendor because all of the vendors used proprietary meta-data formats to store the applications. So applications developed on one tool could not be shared by another. As these tools matured I observed a trend; most of the independent tool vendors got acquired by the IVR platform vendors. And as they were acquired they evolved into tools that took advantage of special features on their platform, effectively making the applications developed on that tool only good for that vendors platform. Wait a minute! We just went full circle and are back to proprietary voice application development tools. How did that happen? My guess is that these IVR vendors do not want you to move to other platforms.
There are some tool vendors that are platform independent, such as VoiceObjects from Voxeo. Even though Voxeo has an IVR plaftorm they continue to have VoiceObjects certified on other vendor platforms. The truth is even though VoiceXML is a standard there are slight variations in how each IVR platform has implemented the standard. With VoiceObjects it is just a configuration change to indicate what platform you are deploying on and it will make the necessary adjustments at run time. You can try this development tool for free and it includes a 2 port run-time. But if you want to deploy the application commercially you have to purchase a per-port run-time license, which is a common business model for these tool vendors.
VoiceObjects, like many other voice application development tools, is an Eclipse plugin. So you have to have some familiarity with the Eclipse IDE and anything you develop outside of the voice application development tools is done in Java. It turns out that the voice application development community is very Java-centric. So what about the poor ASP.Net developer who wants to develop voice applications.
In this series I am going to explore ASP.Net technologies and methods for developing voice applications that I think rival the productivity in some of the third party tools available today. The other advantage to this approach is if you are already an ASP.Net developer you are already familiar with the tools and techniques we will be using. Also there are no new tools to purchase and learn and there are no additional run-time cost above the web server cost.
I will be validating the samples using Voxeo's IVR platform. The reason I will be using this IVR platform is their technology rocks, it is simple to use, they are very close to the latest version of the standards, their extreme support is bar none, and it is free for developers. If you are experimenting with voice application development be sure to get a developer account at Voxeo. You can run applications in their cloud or download a 2 port IVR to run on your workstation for free.
First I will look at using MVC 3.0 and Razor as the basic technologies for rendering VoiceXML pages to the IVR platform and controlling the application flow. Other technologies I plan on exploring are Workflow Foundation (WF) for control flow and Entity Framework (EF) for persisting application data. So if you are an ASP.Net developer and interested in developing voice applications stay tuned.
I have been developing voice/speech applications for over 20 years and a lot has changed over these years. The biggest change was from developing in proprietary development environments supplied by each IVR vendor to IVR platforms that supported open standards like VoiceXML and CCXML that were controlled by the World Wide Web Consortium (W3C). These open standards radically changed how voice application were developed, moving to more web-centric tools and promises of making every web developer a voice application developer. Well almost. It made the transition easier in that the developer could still leverage there skills in areas like JavaScript, XML, web servers, and other web development technologies. But they still needed to learn voice user interface (VUI) design, grammar development, and of course this new language called VoiceXML.
The industry embraced these open standards, partially because their customer base demanded it. Customers saw the benefit of open standards that promised to allow them to develop a voice application once and it could be moved to any platform. Prior to this customers were usually locked in to an IVR platform because moving to another platform required rewriting the whole application on the new vendors tools. This was expensive because often the application development cost would come close to or exceed the equipment cost.
Then came along the tool vendors promising to make it easier to develop voice applications in this new paradigm. These vendors promised productivity gains while allowing you to develop the application once and it would run on any IVR platform. I have tried many of these tools and in reality I did not see the productivity gains that were promised and it was a steep learning curve to do much of anything with these tools. Now instead of being locked in with an IVR platform vendor you were now locked in with a tool vendor because all of the vendors used proprietary meta-data formats to store the applications. So applications developed on one tool could not be shared by another. As these tools matured I observed a trend; most of the independent tool vendors got acquired by the IVR platform vendors. And as they were acquired they evolved into tools that took advantage of special features on their platform, effectively making the applications developed on that tool only good for that vendors platform. Wait a minute! We just went full circle and are back to proprietary voice application development tools. How did that happen? My guess is that these IVR vendors do not want you to move to other platforms.
There are some tool vendors that are platform independent, such as VoiceObjects from Voxeo. Even though Voxeo has an IVR plaftorm they continue to have VoiceObjects certified on other vendor platforms. The truth is even though VoiceXML is a standard there are slight variations in how each IVR platform has implemented the standard. With VoiceObjects it is just a configuration change to indicate what platform you are deploying on and it will make the necessary adjustments at run time. You can try this development tool for free and it includes a 2 port run-time. But if you want to deploy the application commercially you have to purchase a per-port run-time license, which is a common business model for these tool vendors.
VoiceObjects, like many other voice application development tools, is an Eclipse plugin. So you have to have some familiarity with the Eclipse IDE and anything you develop outside of the voice application development tools is done in Java. It turns out that the voice application development community is very Java-centric. So what about the poor ASP.Net developer who wants to develop voice applications.
In this series I am going to explore ASP.Net technologies and methods for developing voice applications that I think rival the productivity in some of the third party tools available today. The other advantage to this approach is if you are already an ASP.Net developer you are already familiar with the tools and techniques we will be using. Also there are no new tools to purchase and learn and there are no additional run-time cost above the web server cost.
I will be validating the samples using Voxeo's IVR platform. The reason I will be using this IVR platform is their technology rocks, it is simple to use, they are very close to the latest version of the standards, their extreme support is bar none, and it is free for developers. If you are experimenting with voice application development be sure to get a developer account at Voxeo. You can run applications in their cloud or download a 2 port IVR to run on your workstation for free.
First I will look at using MVC 3.0 and Razor as the basic technologies for rendering VoiceXML pages to the IVR platform and controlling the application flow. Other technologies I plan on exploring are Workflow Foundation (WF) for control flow and Entity Framework (EF) for persisting application data. So if you are an ASP.Net developer and interested in developing voice applications stay tuned.
Comments
Post a Comment