….::: VOX POPULI :::….

Make the Cloud Listen (and Understand)

Posted by Mark Headd under Development Tools, Open Source, Tropo, Tutorials

Yesterday I wrote a post about the changing cloud telephony landscape, and highlighted some key factors that will dictate which cloud telephony providers are around for the long haul and deliver the next innovations.

One of those factors - support for speech recognition - is a good differentiator for developers to use when choosing a cloud telephony platform.

Speech recognition is becoming increasingly important in our everyday lives. Smartphones and powerful handheld devices enable multimodality, and there are more and more restrictions placed on our use of phones while doing other tings (like driving).

Plus, I can’t think of a more deflating concept than a cloud telephony provider that allows developers to build sophisticated apps and mashups in the language of their choice but that chains users of those apps to a telephone keypad. No fun.

To give an example of how powerful speech recognition can be, and how easy it is to use with a cloud telephony provider that supports it, I worked up a small demo to illustrate the point. The sample code for this demo is on Github, and we’ll dive into it in more detail below.

This demo uses two PHP libraries that are designed to work with the Tropo platform (one of the only cloud telephony providers to support speech recognition):

• A set of PHP classes for working with the Tropo WebAPI.
• A PHP library for creating SRGS grammars in XML format.

If you’ve read any of my previous posts on build applications for the Tropo platform, you’ll see lots of similarities between this and previous sample apps. Here I continue my use of the insanely awesome Limonade Framework for PHP.

Let’s take the example of a company directory that allows callers to dial a single number, select a person or department at the company and then be transferred to the person they select.

With cloud telephony, there is no need to have such a system live on a machine in the server room - it can be hosted externally in the cloud, making it easier to manage and to scale. In addition, with the Tropo Platform, it doesn’t have to be the same tired old DTMF-based menu telling callers to press an extension number or to “dial by name…”.

Using the PHP WebAPI Library and Limonade, we can construct a simple, yet power script that looks like this:

This script is pretty self-explanatory, but there are some key points I want to emphasize. First, note the $options array that holds the reference to an external grammar file (more on that in a bit). Tropo seems to need for this reference to be an absolute one and not a relative reference to the file (not hard to do with PHP - you just need to be aware of it).

Also, the file reference needs to include a trailing parameter indicating that this is an XML grammar (;type=application/grammar-xml). This seems to be true even if the grammar file is served with the correct MIME type by whatever is serving it.

Now lets have a look at this grammar file.

This simplistic example demonstrates how to use the PHPGrammar library. Note the simple array structure that is being used to hold the details of employees for our fictitious company. This could very easily be replaced with a dip into a data source of pretty much any kind, like an LDAP directory or database holding employee details.

Also note in this example that we want to do something referred to as Semantic Interpretation. Our grammar file is a set of rules that will be applied to what the caller says - Semantic Interpretation (SI) dictates the value that is given to our application from the grammar when a successful match occurs.

In this example, we want the caller to be able to say the name of the person they want to be transfered to. We make the first name optional so they may either say the last name of the person or (optionally) the full name. Obviously this may need to be changed based on the size of the directory to render in a grammar file (e.g., multiple employees with the same last name).

Do note that the Tropo platform seems to require the “Script” sytax for returning SI values on a successful match as opposed to the “String Literal” syntax. (More on these alternatives here.)

Works on Tropo (Script syntax):
<item>foo<tag>out=”bar”;</tag></item>

Does not work on Tropo (String Literal syntax):
<item>foo<tag>bar</tag></item>

So, when a caller says the name of a person in our company directory we want to return the number for that person to our Tropo script so we can transfer the call to them. This can clearly be seen when we examine the Result object that is delivered by the Tropo platform.

Tropo’s Result object includes the full grammar engine output, and lots of very detailed information about the recognition. As you can see, the utterance that the speech recognition engine heard was the name of one of our faux employees. The value that was returned is the number of that person.

We use this value in the transfer_call() method of our Tropo script.


// Create a new instance of the Result object.
$result = new Result();

// Get the value of the selection the caller made.
$phone = $result->getValue();

// Create a new instance of the Tropo object and transfer the call.
$tropo = new Tropo();
$tropo->transfer('+1'.$phone);

// Write out the JSON for Tropo to consume.
$tropo->RenderJson();


Using the PHP WebAPI library, it takes just 5 lines of code (excluding comments) to get the value of the grammar result and transfer the call. How cool is that?!

Obviously there are lots of things that can be done to enhance this script, to make it more robust, but it illustrates the essential concepts of speech recognition in the cloud.

What’s more, because of all of the great functionality provided by the Tropo cloud platform we can really push the envelope on the tired old company directory:

• We could take an inbound call from a Skype user and transfer to a cell phone (or a SIP endpoint).
• We could let our caller select a department in our company and then ring several different numbers at once, transferring the call to the first one answered (sort of a “hunt group in the cloud”).
• We could use Tropo’s built in IM capabilities to send a screen pop to the person receiving the call.

The sky is the limit. Which I guess is the point of cloud telephony…

Building Cloud Communication Apps with Tropo: Part 4

Posted by Mark Headd under Development Tools, Tropo, Tutorials, Twitter

This post is the final installment in the series on building cloud communication applications with Tropo, the PHP WebAPI Library and the Limonade framework for PHP.

If you’re just starting, you can take a look back at part 1, part 2 and part 3 to get caught up.

In the last installment, we finished our first complete script using the PHP WebAPI Library and Limonade. We tested this script by calling it using one of the numbers automatically provisioned for applications on the Tropo platform. In this case, we used the auto provisioned Skype number to make test calls.

In this post we’ll refine our script by optimizing it so that the exact same code can efficiently service users on an array of different communication channels. This is the definition of “multi-modality,” and the Tropo platform does it better than pretty much any other platform currently available to developers.

So Many Channels, So Little Code

Tropo’s strong suit is empowering developers to build applications that work across multiple channels from the same code base. Enabling different channels for existing application is easy - log into your Tropo account and go to “Your Applications.” Select the application we’ve been using for this series, and make note of the sections entitled “Phone Numbers” and “Instant Messaging Networks.”

To SMS-enable your application (so that users can simply send a text message to get weather information) select Add a New Phone Number. The phone number you add can be used for both voice phone calls and for SMS messages. Under “Instant Messaging Networks” you can add any one of the many networks supported by Tropo - for this example, we’ll add a Jabber account so we can test a channel other than voice.

If you set up a Jabber account for your app, you can interact with it by sending it a message - try starting things off by sending a simple message like “Hello.” Once you do, you’ll see the same series of prompts that you can hear when you call into your application via Skype.

Now that we can see how our application behaves when we interact with it using an IM client, it becomes obvious that there are some things we’d like to change to optimize it for this channel. User interface elements like a welcome message, reprompts (playing a prompt over again when a user has not entered any input), etc. don’t really make much sense in the context of an IM session. More importantly, it would be nice if we could simply send a zip code to our application to begin the session, as opposed to sending a message like “Hello.”

Fortunately, Tropo was built with multi-modality baked into it so changes like these are rather trivial. To illustrate how to optimize our application so that it can be used on multiple channels, consider the Session object we examined in detail in one of the previous posts in this series.

That Session object was created when we placed a phone call to our application - note that the property name initialText is null.

When we access our application using an IM client, the Session object looks like this:

This Session objects looks considerably different than the one created when we made a phone call to our application. In particular, you can see that the initialText property is now populated with the text we first sent - the string “Hello.”

We can access this property using the PHP WebAPI Library like so:

$session = new Session();
$initial_text = $session->getInitialText();

After accessing the value of this property, we need to do something with it:

if(strlen($initial_text) == 5 && is_numeric($initial_text)) {
	// Since the user submitted a zip code, look up weather info.
}

Now that we can access the initialText sent to our application, and we can examine it to determine if the user has sent us a valid zip code. This allows us to tailor the behavior of our app more efficiently to an IM channel without changing how it behaves when a caller makes a telephone call to it.

The modified script with changes to optimize it for IM can be found here.

Conclusion

Clearly there are lots of other things we could do to tweak our application, to tailor it more efficiently to different channels supported by Tropo. For example, breaking out the weather information into discreet segments for temperature, wind, etc. (by using a separate Say object for each) might work well with a voice or IM channel, but it would probably not work well for SMS or Twitter.

Additional changes to optimize this script for these other channels is pretty straightforward. I won’t get into it in this post, but now that you’ve got the hang of how easy it is to create multi-modal communication apps with Tropo, Limonade and the PHP WebAPI Library you should give it a try.

Rock on!

Building Cloud Communication Apps with Tropo: Part 3

Posted by Mark Headd under Development Tools, Tropo, Tutorials, Twitter, VoIP

This post is a continuation of the series on building cloud communication applications with Tropo, the PHP WebAPI Library and the Limonade framework for PHP .

If you’re just starting, you can take a look back at part 1 and part 2 to get caught up.

In this post, we’ll continue our work from the last post and complete a simple, yet powerful multi-channel application that can be accessed via telephone, SMS or IM client.

In the previous post, we looked closely at the Session and Result objects - these are JSON objects that are sent to your application by the Tropo platform that contain information about how a user is accessing your app (i.e., through which channel) and any input they have provided in response to prompts. If you worked through the last post, you have a partially complete script that looks like this:

You should save this script to a server that can be accessed by the Tropo platform - any web hosting platform that supports PHP >= 5.2.0 will do. Let’s call our script get_zip_code.php.

When you set up the start URL for this script in the Tropo Application Manager, you’ll want to structure it like so:

http://name_of_my_host.com/path/to/get_zip_code.php?uri=start

As you can see, we’ve added a querystring parameter called uri. This will ensure that the initial HTTP POST to this script by the Tropo platform matches our /start pattern and executes our zip_start() method, which is where we want users to begin. Make sure you review the Limonade documentation on setting up routes, as there are multiple options for configuring route pattern matching.

Next, we’ll want to start modifying our partially constructed script. First go to step 6 in the zip_start() method, where we had set up a PostBin URL for Tropo to send a user’s input to so we could examine the Result object. Now that we know what the Result object looks like, we want to start using it to look up information and present it to the caller.

You’ll want to set up a URL to the get_zip_code.php script that will match the route for the zip_end() method. This is where we will access the Tropo Result object and process it. Change the URL in the “next” array element to look like this:

$tropo->on(array(”event” => “continue”, “next” => “get_zip_code.php?uri=end“, “say” => “Please hold.”));

This change tells Tropo that when the “continue” event is raised (after the caller has completed entering input) POST the Result object back to the get_zip_code.php script using a relative URL and a querystring parameter that will ensure matching of our /end pattern.

Next, we need to build out the zip_end() method to process the results:

dispatch_post('/end', 'zip_end');
function zip_end() {

        // Step 1. Create a new instance of the result object
	$result = new Result();
	$zip = $result->getValue(); // get the value of the user input.

        // Step 2. Get weather information for the zip code the caller entered.
	$weather_info = getWeather($zip);
	$city = array_pop($weather_info);

        // Step 3. Create a new instance of the Tropo object.
	$tropo = new Tropo();

        // Step 4. Begin telling the user the weather for the city their zip code is in.
	$tropo->say("The current weather for $city is...");

        // Step 5. Iterate over an array of weather information.
	foreach ($weather_info as $info) {
	    $tropo->say("$info.");
	}

        // Step 6. Say thank you (never hurts to be polite) and end the session.
	$tropo->say("Thank you for using Tropo!");
        $tropo->hangup();

        // Step 7. Render the JSON for the Tropo WebAPI to consume.
       return $tropo->RenderJson();

}

As you can see, our zip_end() method looks similar to our zip_start() method - both use a Tropo object to format information that will be presented to the user, and both call the RenderJson() method of the Tropo object at the end.

You may be wondering about the getWeather() method that is called in step 2. Let’s build that out now and examine how it works - to keep things simple, we’ll make use of the Google Weather API, which provides weather information by zip code and returns the information in XML format.

// The URL to the Google weather service. Renders as XML doc.
define("GOOGLE_WEATHER_URL", "http://www.google.com/ig/api?weather=%zip%&hl=en");

// A helper method to get weather details by zip code.
function getWeather($zip) {

	$url = str_replace("%zip", $zip, GOOGLE_WEATHER_URL);
	$weatherXML = simplexml_load_file($url);
	$city = $weatherXML->weather->forecast_information->city["data"];
	$current_conditions = $weatherXML->weather->current_conditions;
	$current_weather = array(
		"condition" => $current_conditions->condition["data"],
		"temperature" => $current_conditions->temp_f["data"]." degrees",
		"wind" => formatDirection($current_conditions->wind_condition["data"]),
		"city" => $city
	);
	return $current_weather;

}

// A helper method to format directional abbreviations.
function formatDirection($wind) {
	$abbreviated = array(" N ", " S ", " E ", " W ", " NE ", " SE ", " SW ", " NW ");
	$full_name = array(" North ", " South ", " East ", " West ", " North East ", " South East ", " South West ", " North West ");
	return str_replace($abbreviated, $full_name, str_replace("mph", "miles per hour", $wind));
}

The mechanics of these functions are pretty straighforward, so I won’t go in to too much detail - you can now see the connection between the call to the getWeather() method mentioned above and the array of weather data that it returns.

The last thing we need to do in order to complete our zip code weather demo script is to finish the zip_error() method. This is a method we’ll use to tell a user an error occurred (never hurts to be prepared for the unexpected):

dispatch_post('/error', 'zip_error');
function zip_error() {

	// Step 1. Create a new instance of the Tropo object.
	$tropo = new Tropo();

	// Step 2. This is the last thing the user will be told before the session ends.
	$tropo->say("Please try your request again later.");

	// Step 3. End the session.
	$tropo->hangup();

	// Step 4. Render the JSON for the Tropo WebAPI to consume.
	return $tropo->renderJSON();
}

In order for this method to be invoked, we need to make sure that we set up the proper handler in our zip_start() method for it. The Tropo WebAPI makes it possible to set up callback methods that handle things when certain events are raised. This is done by using the On object.

Setting up an event handler using the On object with the PHP WebAPI Library is easy. In fact, we’ve already done it once - look at the zip_start() method and you’ll see a hander for the “continue” event (which is raised when a user has finished entering the proper input). We want to set up something similar for when an error event is raised. Let’s add a handler in our zip_start() method for an error event:

	// Step 6. Tell Tropo what to do when the user has entered input, or if there is an error.
	$tropo->on(array("event" => "continue", "next" => "get_zip_code.php?uri=end", "say" => "Please hold."));
	$tropo->on(array("event" => "error", "next" => "get_zip_code.php?uri=error", "say" => "An error has occured."));

Our script is now complete and ready to test.

Make sure you log into your Tropo account and set up the start URL to your script as discussed above. You can test this script with the phone numbers that are automatically provisioned by Tropo when you set up your account.

Tropo will automatically provision a Skype number, a SIP number and an iNum. You can additionally add a PSTN number in a range of different area codes at no charge. This PSTN number can also be used to send an SMS to, so you can interact with this script via text message. Additionally, you can add an IM account, so you can test this script using your favorite IM client/network.

You may notice, if you test this script using SMS or IM that there are things that don’t yet work perfectly. In the next post, we will make some very simple changes to this script to optimize it for use with SMS and IM (and even Twitter!).

This will transform our simple PHP script into a powerful unified communications application.

Stay tuned…

Building Cloud Communication Apps with Tropo: Part 2

Posted by Mark Headd under Development Tools, Tropo, Tutorials, Twitter, VoIP

This post is a continuation of the series on building cloud communication applications with Tropo and the PHP WebAPI Library.

In this post, we’ll be looking at Tropo’s support for multi-channel applications and using the incredibly flexible and powerful Limonade library for PHP (think Sinatra for PHP).

Working with the Session Object

As I explained very briefly in the previous post on this subject, the Tropo WebAPI is an HTTP/JSON API for building multi-channel communication apps.

What this means essentially is that the Tropo platform does all of the hard stuff involved with executing a communication app - DTMF/speech recognition, rendering Text-To-Speech (TTS), maintaining and managing all of the connections to the different communication networks (PSTN, SMS, IM networks, Twitter). You tell Tropo how to govern the interaction between a caller and your application on a specific channel by sending it a set of instructions in JSON format.

In this series of posts, we’re using the PHP WebAPI Library for Tropo to generate the JSON that gets sent to, and consumed by Tropo. But this exchange of JSON isn’t one-way - Tropo also sends JSON packages to your application with important information about (among other things) the network a user selects to interact with your application on and any input they have provided in response to prompts.

At the beginning of a user session (when a user first connects to your application), Tropo will deliver a JSON Session object to your application. This object contains all sorts of useful information that your app can use when rendering out JSON instructions to send back to Tropo. Let’s examine what a real life Session object looks like.

The easiest way to do this is to simply go over to PostBin.org and make a new PostBin. PostBin is a service that lets you see HTTP posts that get sent to the special URL that is generated when you create a new PostBin.

After you have created a new PostBin, log into your Tropo account and create a new WebAPI application. Use the PostBin URL as the URL that powers your new Tropo WebAPI app. After your app is created, you will have a newly provisioned Skype number that you can use to call it.

When you call your application using the Skype number provisioned by Tropo, you won’t hear anything - remember, we haven’t yet generated any JSON to tell the Tropo platform what to say or do when a user connects. After you make your call (it will be over quickly), go back to your PostBin URL (you may need to refresh) and you will see an object in JSON format, like this:

This is the Session object for the call you just made. It’s what is sent to your application (via HTTP POST) each time a new session is started on Tropo. Working with this object using the PHP WebAPI Library is easy. You just create a new instance of the Session object in PHP and you can start accessing the properties of this object:


$session = new Session();
$from_info = $session->getFrom();
echo $from_info['channel'];

// Using the example Session object JSON from above would render VOICE.


Being able to access the channel and network a user is accessing your application from can be useful when you want to tailor prompts or actions to a specific channel - e.g., a phone call vs. an IM session.

Also make note of the initialText property - this will be important when building SMS and IM applications, where a user will begin an interaction with your application by sending information to it. This property will allow you to process the initial input for those channels without having to ask the user for it again (something users generally dislike).

Next, let’s take a look a the Result object that is sent from Tropo to your application when a user provides input in response to a prompt or direction. In order to do this, we need to take a sip of Limonade.

Mmmm… Limonade!

Limonade is a lightweight PHP framework that is very much like the Sinatra framework for Ruby. I won’t go into too much detail on it, as there is ample documentation available on the Limonade site , but here is quick introduction that will let us build enough of a structure to see the Tropo result object.

When you use Limonade, you set up routes for HTTP requests. A route is comprised of an HTTP method, a URL matching pattern and a PHP method. When an HTTP request is made to a URL that matches the pattern, and uses the method specified in the route, the designated PHP function gets invoked. For example:

dispatch_post('/', 'test');
  function test() {
    echo 'This is a test.';
}

The ‘dispatch_post()’ directive specifies that the HTTP method for this route with be POST (which is what is used by Tropo to send JSON to your application). The two parameters to this directive specify the URL pattern to match (in this case, the root directory on the domain were this script is located) and the PHP method to invoke, which is defined below this directive. In a nutshell, whenever an HTTP POST is made to the root domain where this script is located, the text This is a test will be rendered.

Let’s build out a simple shell that we’ll use to construct our Tropo application for the next few posts in this series:

// Include Tropo classes.
require('TropoClasses.php');

// Include Limonade framework (http://www.limonade-php.net/).
require('path/to/limonade/lib/limonade.php');

dispatch_post('/start', 'zip_start');
function zip_start() {
	// Tell the user to enter their zip code.
}

dispatch_post('/end', 'zip_end');
function zip_end() {
	// Do something with the entered zip code.
}

dispatch_post('/error', 'zip_error');
function zip_error() {
	// Tell the user an error has occurred.
}

// Run this sucker!
run();

Our Tropo application will collect a user’s zip code and then look up some information based on the input they provide. As you can see, we’ve included the PHP WebAPI Library and the Limonade Framework. We’ve also set up three Limonade routes start, end and error (all using the HTTP POST method) and stubbed out the PHP function that will render JSON for Tropo to consume.

To get a look at the Tropo Result object, lets add some logic to the zip_start() function:

dispatch_post('/start', 'zip_start');
function zip_start() {

	// Step 1. Create a new instance of the Session object, and get the channel information.
	$session = new Session();
	$from_info = $session->getFrom();
	$network = $from_info['channel'];	

       // Step 2. Create a new instance of the Tropo object.
	$tropo = new Tropo();

	// Step 3. Welcome prompt.
	$tropo->say("Welcome to the Tropo PHP zip code example for $network");

	// Step 4. Set up options for zip code input.
	$options = array("attempts" => 3, "bargein" => true, "choices" => "[5 DIGITS]", "name" => "zip", "timeout" => 5);

	// Step 5. Ask the caller for input, pass in options.
	$tropo->ask("Please enter your 5 digit zip code.", $options);

	// Step 6. Tell Tropo what to do when the user has entered input. Enter your PostBin URL in the "next" array element.
	$tropo->on(array("event" => "continue", "next" => "http://www.PostBin.org/xxxxxxx", "say" => "Please hold."));

	// Step 7. Render the JSON for the Tropo WebAPI to consume.
	return $tropo->RenderJson();

}

As you can see, inside this function we create a new instance of the Session object and get the channel the user is accessing our application from. We also create a new instance of the Tropo object (this is what we’ll use to send JSON instructions back to the Tropo platform).

The next several steps are fairly self explanatory, but take special note of Step 6. Here we are telling the Tropo platform that when a ‘continue’ event is raised (when a user finishes entering input) tell them to ‘Please hold’ and then POST the results of their input to a PostBin URL. (Note - replace the value above with the PostBin URL you used at the beginning of this tutorial.)

Working with the Result Object

Save your script and change the URL for your WebAPI application in the Tropo Applications manager to point to it. You can now test your script using the the Skype number for your app as we did before . When you access your script, you’ll get the instructions to enter a zip code, after which Tropo will POST the results to the PostBin URL you inserted into the script in Step 6 above.

Now, when you look at your PostBin URL, you’ll see something like this:

As you can see, the Result object that gets sent from Tropo to your app has a wealth of information on what the user entered, how it was interpreted by Tropo and even the confidence level of the recognition (if speech recognition is used).

You can access the Result object using the PHP WebAPI Library just like you can the Session object:

$result = new Result();
$zip = $result->getValue();
echo $zip

// Using the example Result object JSON from above would render 12345


You would use the Result object in the zip_end() function we stubbed out above. You use the value of the zip code entered to look up information relevant for that zip code (like a weather forecast) and present it to the caller.

In the next post in this series, we’ll complete our simple zip code example by adding a weather forecast lookup and present it to the user. We’ll also tweak our script to optimize it for different channels that a user might employ to access it, to ensure the experience is optimized for phone, IM and SMS.

Stay tuned…

A ‘Glass Half Full’ View of Government App Contests

Posted by Mark Headd under Development Tools, Open Government

An increasing number of people are starting to suggest that the concept of the “app contest” (where governments challenge developers to build civic applications) is getting a bit long in the tooth.

There have been lots of musings lately about the payoff for governments that hold such contests and the long term viability of individual entries developed for these contests. Even Washington DC - the birthplace of the current government app contest craze - seems the be moving beyond the framework it has employed not once, but twice to engage local developers:

“I don’t think we’re going to be running any more Apps for Democracy competitions quite in that way,” says Bryan Sivak, who became the district’s chief technology officer in 2009. Sivak calls Apps for Democracy a “great idea” for getting citizen software developers involved with government, but he also hints that the applications spun up by these contests tend to be more “cool” than useful to the average city resident.

App Contests Abound

This view is starting to crystallize against the backdrop of an ever greater number of app contests being held. At the recent Gov 2.0 Expo in Washington DC, Peter Corbett of iStrategy Labs (who helped launch the first government app contest in DC) gave a presentation that listed several dozen governments around the globe that had recently completed an app contest or were scheduled to soon start one.

And the biggest app contest to date - being sponsored by the State of California - is slated to begin soon. (Two fringe technology companies that you’ve probably never heard of - Google and Microsoft - are set to partner with the Golden State for this 800 pound gorilla of government app contests.)

So if app contests are being used in more and more places, and the size and scope of these contests keeps growing, what’s with all the hand wringing of late?

Lessons Learned from App Contests

My take on app contests is not an unbiased one. I’ve been a competitor in three different app contests (the original Apps for Democracy, the original Apps for America, and the NYC Big Apps competition) and was recognized for my work in them. Outside of contests, I’ve build applications using open government data and APIs for the cities of Toronto and San Francisco, and for the New York State Senate.

Clearly I am a supporter of the concept of the government app contest.

Having said that, though, I do think that those taking a more skeptical view of app contests are asking some important questions. The government app contest has come a long way since Vivek Kundra was in the driver’s seat in the DC technology office. It’s time to start asking how app contests can be improved.

But before we move on to that discussion, it is worth noting the lessons that have been learned over the last two years or so from government app contests.

First, governments and citizens benefit when high value, high quality data sets are released by governments that are in machine readable formats, easily consumed by third party applications. Believe it or not, there is still debate in many places on this point. App contests prove the theory that publishing open government data provides tangible benefits.

Second, app contests prove that it is possible to engage and excite both developers and high level elected officials about open government data. The cause of open government can’t be anything but well served when these two groups are excited about it, and appealing to both successfully in equal measure is usually very challenging.

Third, and maybe most importantly, government app contests provide sort of a “petri dish” for government officials to see how government data might be used. They let governments solicit ideas from the private sector about the different ways that open data can be used in a manner that is low risk and low cost. Some of the proposed uses of government data that emerge from these contests – whether its tweeting a recorded message to your Congressman, or using an IM client to browse campaign finance data – might never be considered by governments but for them running an app contest.

These lessons aside, there are those who contend that the existence of app contest entries that have languished (or even been abandoned altogether) after a contest is over suggests that an app contest didn’t work well (or as well as it should have). I don’t think this is necessarily the case.

Look at it this way; once a government has decided to publish open data sets and enable the development of one single app by an outside developer, the marginal cost of the next app (from the perspective of government) is essentially zero.

Once a data set has been put into a machine readable format and staged for download so that it can be used by a developer or third party, what is the cost of the next download? Or the next 50, or 100? Essentially nothing.

The road to tech startup profitability and success is a long and hard one, and it’s littered with the hollowed out husks of ideas (some very bad, some very good) that for one reason or another just don’t make it.

Should we be overly concerned that the dynamic of government app contest entries is essentially the same as it is for any other sort of technology startup project? Personally, I don’t think so.

Making App Contests Better

I do however, think there are some things that government app contests organizers can do a better job on.

Most notably, government engagement with app developers over the long-term has proved to be somewhat challenging. Gunnar Hellekson of Red Hat has observed the same phenomenon:

“..I would think that one of the desired outcomes [of an app contest] was an ongoing community of developers that are producing and maintaining applications like this — whether it’s for love, money, or fame. It would be a shame to see hard work like this die on the vine because we’ve lost the carrot of a cash prize.”

I don’t think this is an issue with developers necessarily – I know there is still lots of excitement around the data sets that have served as the foundation for app contents that are now over. I think the issue is that governments do not always have a plan for post-contest developer engagement.

Once the prizes are given out, and the award ceremony is over, there are no plans or strategies in place to keep developers engaged over the long haul. I do not believe this is an issue of money – not every developer is looking for a cash prize, and there are some good examples of government agencies (MassDOT and BART among them) who do a pretty good job of keeping developers engaged without contests.

I also think that a greater emphasis could be placed in app contests on developing reusable components (as opposed to user-facing solutions) that can be released as open source software and used by anyone to consume data or interact with a government API. I’m talking specifically about things like open source libraries for interacting with the Open311 API – tools and libraries specifically designed to make it easier to use open government data.

The easier it is to use government data and APIs the more people will do it, and the more development of reusable components as a by product of app contest, the less angst there will be about projects that don’t remain viable long-term. If one of the requirements of entry is the use (or reuse) of common components, even contest entries that fizzle out down the road will have made a tangible contribution to the open data effort.

I think with a few simple changes, app contests can continue to be used as an effective tool by governments to encourage the development of cutting edge applications powered by “democratized” government data.

Building Cloud Communication Apps with Tropo: Part 1

Posted by Mark Headd under Development Tools, Tropo, Tutorials, VoIP

A few months back, I wrote a series of posts on building NoSQL telephony applications with Tropo and CouchDB. Today I’m going to start a continuation of that series, focusing on how to build cutting edge cloud communications apps with the Tropo WebAPI.

What is the Tropo WebAPI?

The Tropo WebAPI is, in a nutshell, an HTTP/JSON API for building multi-channel communication applications - applications that you interact with via phone, IM, SMS or Twitter. While my earlier series on Tropo focused on building applications in Tropo’s scripting environment (another fine option for developers), this series will focus on building JSON-based applications (generated using PHP) that can be hosted anywhere and executed in the Tropo cloud environment.

Faithful readers will recognize some similarities here to a post I did a while back on the HTTP/JSON API provided by CloudVox, another cloud telephony provider. While the concept behind these two API’s is very similar, there are some key differences that make Tropo a highly attractive option for developers.

First, the Tropo service is truly multi-channel - using the Tropo WebAPI you can build applications that work on a range of different communication channels, not just phones (although you can build some pretty slamming phone apps as well).

Since I’m a phone app developer at heart, some of the features that Tropo provides for phone applications really get me excited. Tropo supports both DTMF entry and speech recognition. It also has broad multilingual support. In addition, Tropo gives phone application developers the ability to manipulate SIP headers, an important feature in building sophisticated cloud communication apps that I hope to demonstrate down the road a bit.

Getting Started

Head on over to Tropo.com and set up a new account (if you don’t have one already). Take a little time to review the documentation for the Tropo WebAPI. For the example applications in this series of blog posts I’ll be using a PHP class library I developed specifically to interact with the Tropo WebAPI.

The crew behind Tropo have provided a Ruby Gem for interacting with the Tropo WebAPI. However, since I like to do my cloud telephony work with PHP I decided to write my own set of classes for doing this. Whether you’re a Ruby-head or a PHP enthusiast, using one of these tools to generate JSON for consumption by the Tropo WebAPI can make build an application significantly easier, particularly as you get into more sophisticated application development.

You can get the PHP Library, as well as some of the sample apps we’ll be looking at, from GitHub:

$ git clone git://github.com/tropo/tropo-webapi-php.git

You’ll need to host these classes and the PHP scripts you write with them on a server that can be accessed from the Tropo environment. Any web server that supports PHP will do.

My First Tropo WebAPI Application

Let’s start with the standard Hello World app:


< ?php

// Include Tropo classes.
require('path/to/TropoClasses.php');

// Create a new instance of the Tropo object.
$tropo = new Tropo();

// Add a prompt to the object using the Say() method.
$tropo->Say(”Hello World!”);

// Render the JSON for the Tropo WebAPI to consume.
$tropo->RenderJson();

?>


You can look at the rendered JSON in your browser, and you should see something like this:


{
    "tropo": [
        {
            "say": [
                {
                    "value": "Hello World!"
                }
            ]
        }
    ]
}


Go to the Applications section in your Tropo account and set up a new WebAPI application that points to the location of this script.

When you create your application, Tropo will automatically provision a Skype number, a SIP number and an iNum. You can additionally add a PSTN number in a range of different area codes at no charge.

You may also notice the section below the provisioned phone numbers entitled “Instant Messaging Networks” - this section allows you to set up any number of different IM accounts (and Twitter!) that your application can use. We’ll dive deeper into this in future posts.

For now, we’ll keep it simple and use the auto provisioned Skype number - when you call this number, you will hear it say “Hello World.”

The next post in this series will focus on a more sophisticated application that uses the TropoPHP classes and the utterly awesome Limonade PHP framework.

Stay tuned…

Building an Open311 Application

Posted by Mark Headd under Cell Phones, CouchDB, Development Tools, Open Government, Twitter

Earlier this year, I had an idea to build a Twitter application that would allow a citizen to start a 311 service request with their city.

At the time, there was no way to build such an application as no municipality had yet adopted a 311 API that would support it (although the District of Columbia did have a 311 API in place, it did not - at the time - support the type of application I envisioned).

That changed recently, when San Francisco announced the deployment of their Open311 API. I quickly requested an API key and began trying to turn my idea into reality.

My idea resulted in an application that I soft launched last week. TweetMy311 is now live and can be used in the City/County of San Francisco to report 311 service requests. The project website has a detailed description of how it works, but its very close to my original idea.

More good news on the Open311 front came recently when it was announced that San Francisco and the District of Columbia had come to agreement on a shared Open311 standard. This means that apps built to work with the San Francisco 311 API will also work with the 311 API in Washington DC. I’m working on enabling TweetMy311 for Washington DC now, and hope to have this service live there in a few weeks.

Ultimately, I hope people use my application, that they like it, and that it makes it easier to report an issue to their municipality. I did, however, have some other motives in developing this application that I think are equally important.

Are You Experienced?

Since 311 APIs are rare, and (right now) applications that use 311 APIs are also rare, I think there is value in being able to capture the experience of developing an Open311 application from scratch. This information can provide tremendous value to the governments that deploy 311 APIs (what works, what doesn’t, what can be improved, etc.), and for developers thinking about building an Open311 application.

I hope to use TweetMy311 to provide feedback to governments that deploy 311 APIs (and to those thinking about deploying one) so that they can get a sense of how the experience works from a developer that has used one. At the end of the day the ease of use of an API, the quality of documentation, the ability to test applications in a meaningful way and a number of other factors will determine how many developers decide to take the step and become a “civic coder” by building an Open311 application.

Getting to Open

For me, the use of open source technologies in TweetMy311 was important. This project provided a great opportunities to learn more about a technology that I have become fascinated with of late - CouchDB. TweetMy311 is a NoSQL application that uses CouchDB at its core. It runs on Ubuntu Linux with Apache and was built with the PHP scripting language (I guess that makes it the CLAP stack - CouchDB, Linux, Apache, PHP)

Building with open source technologies was important because I hope to be able to share the code I have developed with interested governments that want to learn how an Open311 application is put together. I also believe it’s important because I think the Open311 initiative can be a great mechanism for encouraging the use of open source technologies.

Leading up to this project, I developed a small PHP library for interacting with the San Francisco Open311 API. I make use of this library in TweetMy311 and any other developer that wants to use it in their project is free to do so. I plan on branching this library soon so that it can work with the new version of the Open311 standard.

Give it a twhirl

So if you live in San Francisco and you want to give TweetMy311 a twhirl, check out the description on the project website. I’d appreciate any feedback - positive or negative - because ultimately I think it will make the project better.

I had a great experience developing TweetMy311, and I learned a lot. I’m looking forward to sharing my experience with interested governments and other developers.

Making Democratic Participation Frictionless

Posted by Mark Headd under Development Tools, Open Government

This week, I had the pleasure of presenting at the Emerging Communications Conference & Awards (eComm) event in San Francisco.

I gave a presentation on the convergence of two powerful trends that promise to deliver more and more choices to people in how to communicate, interact and transact with their governments. The first is the growing trend toward more transparent government. By this I mean the efforts by governments around the globe and across this country to release meaningful, high-value data sets in formats that are designed to be used by third-party developers and applications.

Photo by James Duncan Davidson

The second is the proliferation of more and more powerful, easy to use tools for developers to build mobile applications - applications that use telephony, SMS, IM and social networking interfaces for interacting with users. I’ve discussed both of these trends at length on this blog in the past, but it was nice to bring them together in one succinct, focused presentation. These two trends are powering disruptive changes, and will have a significant effect on how citizens communicate with their governments in the future.

By enabling the development of new, more sophisticated, more powerful applications, these two trends will enable a greater array of options for citizens in how they interact with government. This choice is central (to my way of thinking) to a vibrant democracy. Healthy democracies are those where participation becomes “frictionless.” Frictionless participation requires choices - the more options people have in how they participate in their democracy, they more likely they are to participate and more active they will become.

I think this is an important discussion, and I hope to have it with more people. You can view the presentation I gave below, or follow this link to SlideShare.

Leveraging the Government Platform

View more presentations from Mark Headd.

I’m looking forward to watching these two trends develop, and to seeing the good things that come out of their convergence.

The American Cell Phone Gap

Posted by Mark Headd under Cell Phones, Development Tools, Digital Divide

A few years back, I wrote and spoke a lot about the importance of the cell phone, and the potential it has to help deliver public services and provide information from government. A lot has changed in those few years, as documented in an illuminating article published recently in the NY Times.

While the U.S. continues its lust for more powerful, sleeker and functionally dubious devices, the rest of the world continues to leverage the power inherent in the ordinary cell phone. The cell phone is at the heart of digital life in other countries, and huge numbers of people have them (or soon will):

The number of mobile subscriptions in the world is expected to pass five billion this year, according to the International Telecommunication Union, a trade group. That would mean more human beings today have access to a cellphone than the United Nations says have access to a clean toilet.

In the U.S., we continue to look to the build out of the broadband infrastructure as a way to connect those who remain unconnected. I can’t help but think (as I have for some time) that the effort to bring more people into the digital age would be enhanced by leveraging what many already have - an ordinary cell phone. There would be a number of advantages to such an approach - as noted in the NY Times article, cell phones are “cheap and shareable and easily repaired.” They also do not present the same learning curve as other digital devices, like laptops or netbooks.

So why isn’t the cell phone (and services like text messaging) as important in the U.S. as it is in other countries? I think part of the answer is that it hasn’t always been easy or efficient to build text messaging applications.

That’s changing - new services like Tropo and Twilio make it (if you’ll pardon the alliteration) trivial to build SMS apps. Certainly other services will soon follow suit, and more powerful tools for building sophisticated SMS and telephone apps will emerge.

As it continues to get easier to build more sophisticated applications, perhaps our use of these devices will change and become more aligned with the rest of the world.

As someone to whom the power of the ordinary cell phone is readily apparent, I sure hope so.

Upgrading to CouchDB 0.11

Posted by Mark Headd under CouchDB, Development Tools, Open Source

Just a few days ago, CouchDB version 0.11 was released - this new version is packed full of cool new features as outlined on the Couch.io blog. It’s also the first release without the Alpha or Beta label attached to it.

What’s more exciting, CouchDB version 0.11 is a feature-freeze release candidate for the upcoming version 1.0. So if you’ve played around with CouchDB and have an old instance laying around, now is the time to upgrade.

If you’ve read my previous series on using CouchDB to build cloud telephony applications with Voxeo’s Tropo platform, and you used my instructions for setting up CouchDB on Ubuntu 8.04, then upgrading to CouchDB version 0.11 will be a piece of cake. (Note - the mirror you download from may be different than below. Go to the download page to find the best one):

Before upgrading, make sure that any customizations you’ve made to the CouchDB configuration are in /usr/local/etc/couchdb/local.ini. The upgrade process will overwrite any changes you have made in default.ini.

$ sudo /usr/local/etc/init.d/couchdb stop

You should probably run make uninstall on the previous version of CouchDB before starting.
If you see leftover files in /user/local
$ find /usr/local -name \*couch* | wc -l

You should probably get rid of them:
$ find /usr/local -name \*couch* | xargs rm -rf

$ wget http://www.trieuvan.com/apache/couchdb/0.11.0/apache-couchdb-0.11.0.tar.gz
$ tar -zxvf apache-couchdb-0.11.0.tar.gz
$ cd apache-couchdb-0.11.0/
$ ./configure && make && sudo make install
$ sudo /usr/local/etc/init.d/couchdb start
$ curl -X GET http://127.0.0.1:5984

You should see:

{”couchdb”:”Welcome”,”version”:”0.11.0″}

Note - if you see an error that says {"error":"error","reason":"eacces"} when trying to create a database or insert documents, you may need to re run some commands listed in the previous install instructions:

$ sudo chown -R couchdb /usr/local/etc/couchdb
$ sudo chown -R couchdb /usr/local/var/lib/couchdb
$ sudo chown -R couchdb /usr/local/var/log/couchdb

I’m in the process of finishing up a project that will make use of the Open311 API deployed by the City of San Francisco and it shall be SQL-free - now that I have CouchDB 0.11 installed, I’m ready to finish up.

Stay tuned - this project is going to kill!