Easier Doesn’t Always Mean Better

I’ve been doing lots of research lately into tools, languages and platforms aimed at making the process of building voice applications easier.

These new tools offer extensions to existing programming languages like PHP and JavaScript, or entirely new XML-based languages for building voice applications. Each of these new approaches has some appeal and each achieves (to some degree) the goal of making voice applications “easier” to build.

Still, these new tools raise some issues that may be reason for concern as well.

Before the advent of VoiceXML, languages and tools used to build IVR systems were vendor-specific. No standards existed that would allow IVR systems built for one platform to be easily and efficiently ported to another.

Certainly there are instances where designing an IVR for a specific platform may rank as a higher priority than making the application portable (i.e., if a platform supports a specific feature that is critical to the application). But having a standard language for building IVRs is good for developers too – if you can learn to build IVRs for one platform, your skills will be portable to other platforms (and to other jobs).

Building good IVR systems is hard. Really hard. Examples of poorly developed systems abound. This is one of the reasons that satisfaction with IVR systems is generally low, and why projects like GetHuman and Fonolo have developed.

But the direct relationship between difficulty and quality isn’t reserved to IVR applications. Building good visual web applications is really hard as well:

How many web applications have you seen where the developer(s) did not think about important issues like accessibility, scalability, security, etc.? How many development projects have you inherited or been involved with that contained poorly written, poorly documented or just straight up broken code? How many stories have you seen that described a web site or application that suffered from a critical security hole that compromised personal information?

I don’t think the answer to raising the satisfaction levels with IVR systems is to lower the barrier of entry (in terms of developer skill and experience) for creating them.

Is it harder for more junior developers to create sophisticated, secure, well built voice applications? Yes. And maybe it should be.

Advertisements

5 thoughts on “Easier Doesn’t Always Mean Better

  1. Hi Mark,

    Very interesting analysis. You’ve done some excellent research into voice platforms.

    Putting on my Twilio hat for a moment.
    You’ve hit on what we think Twilio is all about: web developers. There is this huge body of talent out there that already knows how to build and scale web applications, why make them learn a new API to build voice apps?

    We strove to make Twilio as web-developer-friendly as possible while allowing developers to use their language of choose PHP/Python/Java/C#/VB etc. While XML is part to our API, there are is also a large RESTful part as well:
    http://www.twilio.com/docs/api_reference/REST/

    While comparisons to VoiceXML and CallXML in inevitable (we created a little comparison here http://www.twilio.com/voicexml-comparison) our goal is to open voice applications up to a whole new audience.

    You are absolutely right there are lots of web developers that did not think about important issues like accessibility, scalability, security but there are lots that do. Here is a short presentation we put together describing the market.
    http://www.slideshare.net/twilio/twilio-web-service-api-for-building-voice-applications-presentation

    As you play around with Twilio, look at common tasks like accessing a recorded messages over the web or playing MP3s. We’ve really tried to lower the bar and make hard stuff easy! If there are things we’ve missed that you would expect to be there let us know.

    -Evan

  2. Evan:

    Thanks for your thoughtful reply. I do think that services like Twillo are a good thing for voice application developers, and skilled developers of any stripe can use Twillo to make sophisticated, well-built, robust voice applications.

    I guess the concern I was trying to express was that satisfaction levels with IVR systems has traditionally been very low. It isn’t hard to find examples of poorly designed IVRs. Part of the answer for addressing this is making the principles of good voice application design more accessible to developers.

    My own personal feeling is that the test of a good voice application development tool is not whether it can make developing voice applications easier, but whether it can make developing good voice applications easier.

    Ultimately, though, I think that new services like Twillo will go a long way toward motivating other platform vendors (VoiceXML platforms in particular) to ensure that their platforms are easy to use and can support robust, well-built voice applications.

    Thanks for the input!

    BTW, I’ve added the Twillo blog to my blogroll.

  3. Bringing voice apps to web developers is what CallXML did… eight years ago. I’ve used both Twilio and CallXML. Both are simpler than the other in various areas. Both can be learned in an hour or two. CallXML has functionality that goes way beyond Twilio’s basic capabilities however: speech recognition, conferencing, multi-leg call control, etc. I’m sure Twillo will try to add these things over time, but as Mark said – alot of telephony is hard. Twillo has taken on only the easy parts so far. Best of luck.

  4. Mark,

    Thanks for the mention.

    It’s true that a lot of people are driven to Fonolo out of frustration with IVRs. But I t see our role as much than an antidote to bad IVR design. Like it or not, the IVR interface is here to stay. First because it serves a gateway to live human interaction (usually a call center) and second because it is truly a least-common-denominator interface. Furthermore, the growing array of tools for building IVRs will drive up their prevalence. What Fonolo does is leverage all the work companies (and IVR developers) have put into this particular interface and make it *better* by automatically adding a visual interface and some “smarts” like Deep Dialing and bookmarking.

    Shai

    Fonolo CEO and co-founder.

    http://www.fonolo.com — Try it out today for free!

  5. Shai – I agree that what Fonolo has done is pretty darn cool. Certainly didn’t mean to pigeon hole you as the antidote to bad IVR design.

    As an IVR developer, though, it is somewhat frustrating to see heaps of scorn placed on IVR systems that are designed poorly when it seems as if there are a lot more web sites that are poorly designed.

    I’ve groused about this in the past, and I’m obviously showing my bias here, but its pretty frustrating to see IVRs get what seems like the brunt of the criticism. (Sorry for the rant…)

    BTW, your on the blog roll now as well. Cheers!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s