Would you like to have your Tropo.com app respond differently depending upon which communications channel is used to connect to the app? Would you like to, for instance, have the app provide more of an introduction to voice callers but not for text channels like IM, SMS or Twitter?

Earlier today, I wrote about how to add Twitter support to a Tropo app and at the end of the piece I mentioned that my Yahoo!Weather sample application responded with more messages that I really wanted it to send via Twitter. In this post, I will show how you can use the “currentCall” session variable to tweak your app to respond differently depending upon which channel is being used.

First, let’s look at how the app originally responded via IM to a ZIP code:

After one IM to the app I received seven responses! Not good. Perhaps in IM it might be okay, but in SMS or Twitter it is a bit too verbose.

REMOVING EXTRA MESSAGES IN TEXT MODE (BUT NOT IN VOICE)

If you look at those messages, the first and last messages are “extra” messages that introduce the app to the user and then clue the user into the fact that the app is done. We could just eliminate them, but then, particularly with the final message, we’re being kind of rude to the person who is calling in. We are just giving the report and hanging up. Perfectly fine in a text-based interaction, but not great for a voice interaction.

To modify the app to respond differently according to channels, we need to use the “currentCall” session variable. With that variable you have access to the parameters of the “callObject“, including, most relevant to this issue, “channel“. So in python, my personal language of choice, I can add this at the beginning:

if currentCall.channel == "VOICE":
    say( "Welcome to the Tropo dot com sample Yahoo weather app." )

and this at the end:

if currentCall.channel == "VOICE":
    say( "Thats all. Goodbye!" )

With those two additions, I’ve now made it so that if you call the application at +1 (407) 374-3994 you will hear those phrases but if you use a text channel (SMS, IM or Twitter) you will not see those messages.

I then went through the python code and eliminated the multiple “say” commands so that the location, time, temperature and condition were all written on one line. The result is that now the interaction is down to 2 messages:

MORE TWEAKING FOR VOICE

This is obviously better, but notice that first message “Enter the ZIP code...“. If you hear that in a voice call, will you realize that you could either enter the ZIP code in digits on your keypad or say the ZIP code? Probably not… you probably think you can only use DTMF digits. So let’s change the prompt a bit:

if currentCall.channel == "VOICE":
    say( "Welcome to the Tropo dot com sample Yahoo weather app." )
    result = ask( "Please say or enter the ZIP code for a weather check", { 'choices' : "[5 DIGITS]" })
else:
    result = ask( "Enter the ZIP code for a weather check", { 'choices' : "[5 DIGITS]" })

Now we have a more friendly prompt for voice that clues people in to the fact that they can either enter digits or use speech recognition.

REMOVING THE INITIAL PROMPT IF DATA IS PROVIDED

The next step is obviously to get rid of that initial “Enter the ZIP code...” prompt for a text channel if a ZIP code is sent in the initial message. This points to a major difference between voice and text channels. With voice, you need to have that initial prompt. With text, the user can already know what they need to send and just send that data along.

The currentCall session variable also has a “initialText” parameter that includes the text sent by the user. So I can see that the next step I need to do is something like:

If currentCall.initialText is a valid ZIP code, don’t send the first prompt. If currentCall.initialText is NOT a valid ZIP code, or is just general text, do send the initial prompt.

Unfortunately: 1) I have to leave in a few minutes to catch a plane to fly back to my home in NH; and 2) I’ve been spending more of my days writing in PowerPoint versus python, so my coding is a bit rusty. My first reaction is just to do a try / except but I know I’ll need to play with it a bit. So I’ll tweak it some more later.

PLAYING WITH THE CODE

If you are a pythonista, you’re welcome to play with my sample app. I uploaded it to Github at:

http://github.com/danyork/tropo-twitter-weather-sample

If you come up with an elegant way to get rid of that initial prompt, I’ll be glad to write about your solution here.

And if you create a similar app in another language, I’m also glad to write about that here as well.

USING OTHER currentCall OPTIONS

Beyond “channel” and “initialText” there are a number of other interesting parameters found on the callObject reference page. While currentCall.channel lets you broadly differentiate between voice and text channels, currentCall.network lets you get even more granular and respond to specific channels differently. And of course currentCall.callerID is always a useful variable to have around.

With that, I’ve got a plane to catch… stay tuned for more…

Related posts:

1. Scaling Your Twitter Support, Part 1a: Tweaking the “Night Service” app a wee bit
2. Scaling Your Twitter Support, Part 2: Triggering Alerts on Keywords
3. Testing a Tropo app with Twitter? Remember that Twitter rejects duplicate tweets…
4. Customer Testimonials Make Everything Worth It!
5. Something Fun and Quick To Make – the Toddler Amusement Line!

Tags: Multi-channel, Programming, Python, Twitter

You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.