If you're using JNDI to connect to your database through Tomcat, then it's possible you've had to deal with database connection pool leaks. Your code tests fine, it's been reviewed, but in load tests or in production your app is unable to acquire database connections, the pool is empty!

Fear not, there are some handy parameters which can be set in your application's XML configuration file (in tomcat/conf/Catalina/YOUR_IP/YOUR_APP.xml):

removeAbandoned: Enables automated monitoring of pooled DB connections, and closes them if they time out. This is a catch-all, which prevents bugs in your code from bringing a system to its knees. If your app fails to close a connection, this will close it after a certain time period.

removeAbandonedTimeout: Sets the timeout value for use with the removeAbandonded parameter.

logAbandoned: Logs stack trace information when a pooled DB connection times out. This is invaluable information which can help you quickly track down the offending lines of code which failed to close the connection.

These helpful parameters are documented here on the Apache Tomcat site, along with many other hints and suggestions.

Posted by Vance at 10:27 AM | Permalink

Mark Gibbs over at Network World has put together a spiffy little scoring system for customer service systems (including many criteria for IVR systems). How would callers score your IVR using Mark's guidelines? Place a call and find out, you may be surprised.

Even if you are still in the development stages, it's worth a read; many of his observations are a quick-n-dirty VUI design lesson. However, I don't necessarily agree with all of his criteria, such as "Subtract one point if there is music on hold" and "Add one point if a human answers". Different callers will value these things in different ways, and an IVR that your customers enjoy using may be more welcome than a live agent.

Here are some highlights:

Subtract three points if the person or IVR tells you that you have to call another number for the service you want. Subtract 1,000 points if the other number is wrong, busy or discontinued.

...subtract three points if you have to listen to a long menu of choices and the IVR won't let you enter your selection until it finishes. Subtract 10 points if the choice you're looking for and what you are offered are completely different.

Subtract 10 points if the first person you speak to does not have [your call] details, and if you get transferred, subtract 10 points for each subsequent person without your details.

Posted by Vance at 05:52 PM | Permalink

Earlier today, as I was typing a comment in our internal issuing-tracking system, I hit backspace to correct a typo. WHAM! I go back to the previous page, and my long-winded comment is gone. Apparently I somehow left the context of the text area (did I tab, or spuriously click, or??), which causes backspace to act as a hotkey for "Back". The web browser was not very forgiving of my mistake.

Are your IVR applications forgiving? They should be.

I can think of one great example. When I call my cell phone provider's voicemail system, and I delete a message, I am immediately given the option "To undelete this message, press 1." If I am checking my voicemails on the go and accidentally hit the 7 key (delete) instead of what I meant to do, this is a lifesaver!

I can also think of many calls (I won't name companies) where I've ended up in some part of the app where I was destined to hear a message and be disconnected. What if I got there by mistake? What if I would prefer to leave a message? Forgive me for not using the app in the way you had forecasted. If I feel that it's impossible to make mistakes while in your app, I probably won't mind using it again.

Posted by Vance at 10:21 AM | Permalink

MVC, or model-view-controller; most programmers have heard this design lauded, but why? Simply put, it allows any one of the trio to be modified (or swapped-out) without affecting the other two. Want to change the label of a menu item? You only have to modify the view. Want to store the information in a database instead of the proprietary format you are currently using? Only update the model.

While the MVC design is commonly used in desktop application development, getting it to work in the web world was previously tedious; that is, until Velocity (from the Apache Jakarta Project) came along.

Continue reading "Velocity offers a revolution in MVC servlet development" »

Posted by Vance at 04:35 PM | Permalink

First, read this woman's story of a customer service nightmare she encountered when her stock trading company was bought out. When the new company's website wouldn't let her login, she turned to their main phone number (an IVR). But the system failed, and it failed miserably.

Ask yourself, as a VUI designer, what could have been done better in this company's IVR, to ensure that customers like her receive quality service?

Continue reading to see some of my suggestions.

Continue reading "What would you do differently?" »

Posted by Vance at 03:41 PM | Permalink

I hadn't intended this to be a multi-part blog thread, but then I noticed that SpeechTEK's website had a short article about a new IVR mini-game that is being used to hype the launch of Ubisoft's new Splinter Cell title. In short, you can call into the system and have a "live chat" with Sam Fisher, who is one of the key figures in the game.

The idea of using IVR for viral marketing campaigns is nothing new. Halo 2, which released not that long ago, included one of the most extensive viral marketing campaigns ever seen, involving movie trailers in cinemas, mock websites, and even outbound calls to various public payphones at certain GPS coordinates that "players" have to discover. While this is very intriguing, it's not really a game in and of itself. It's a prelude to a game, it's a non-repeatable experience.

More along the lines of my previous post is a game called Majestic, which is now several years old. This game tries to create an alternate reality for the player, by interfacing via telephone, fax, IM, and email. But it was over-hyped and received very poor reviews on release.

We are still waiting for that killer app I previously alluded to. And using IVR games solely for marketing purposes is not going to get us there.

Posted by Vance at 09:38 AM | Permalink

The game development industry has been busting at the seams with buzz about game development for cell phones. But what about games for the telephone everyone has at home?

And I'm not talking about odds-based contests, where you may or may not win a prize depending on if you're the lucky caller. I'm talking about games that people actually want to call in and interact with on a daily basis -- for fun.

Think about the potential:
* Everyone has the required gaming console at home (neither Sony nor Nintendo can beat that).
* People are familiar with the interface and may already engage in fun via phones (e.g. chat lines, walkie talkies, etc.)
* Inherent ability to support a multi-player environment (everyone is calling into a central location, can have a DB, etc.)

I believe the market is just waiting for the first killer app, and then this unknown industry will break wide open.

Posted by Vance at 02:03 PM | Permalink