DC Crime Finder

The “DC Crime Finder” is a multimodal app that lets residents of the District of Columbia search for crime locations in their neighborhoods.

It uses actual crime data published by the District and supports a wide range of devices for looking up addresses and crime locations. The DC Crime Finder works with traditional desktop web browsers, mobile devices and PDAs, smart phones, iPhones, G1 phones — essentially any device that has a web browser and access to the Internet.

The application also works with ordinary cell phones and even land line phones. It sports a voice user interface (VUI) which makes it accessible from any old school telephone — even a rotary phone (if anyone in DC still has one).

This application is my submission to the Apps For Democracy contest being sponsored by the District of Columbia and iStrategyLabs.

Get the App:

The source code for the application is hosted on Google Code.

Its written in PHP and makes use of the HAWHAW PHP library by Norbert Huffschmid. This application should run equally well on Linux or Windows (I developed it on Ubuntu 8.04), but you’ll need PHP 5 with SOAP support enabled.

You’ll also need a MySQL database — the District of Columbia provides information on crime locations in a variety of formats, including real time XML-based feeds. For this application, I opted to go with data in CVS format that I imported into a simple MySQL table. One of the things the application does is to calculate the distance of crime locations from a specific address. I believe that this calculation is much more efficiently done in the context of a database, rather than trying to use a real time XML feed (there are a lot of crime locations).

The other requirement, if you want to hear this application on a standard telephone or cell phone, is to grab a copy of Voxeo Prophecy. This app should run on most mature VoiceXML/CCXML platforms, but Prophecy is by far the easiest to use and the most standards compliant. Best of all, its free to download and use. If your interested in developing other telephone applications, consider signing up for a free developer account with Voxeo.

Test the App:

I’ve set up a demo of this application in a test environment. You can look at the visual interface for this application (which uses a simulator to mimic the look and feel of a cell phone browser) by clicking here (demo is no longer active). Any mobile device with a browser can also access the application — the HAWHAW library uses some pretty slick device detection, so any device that can handle it should get standard XHTML. Smaller, or older devices will get old school WAP markup.

See what this app looks like in an older iPaq handheld device.

The beauty of this application is that when a voice browser (like Voxeo Prophecy) comes a knockin’ it gets its standard markup language – VoiceXML. If you want to hear this application on a telephone, simply dial (202) 684-7894. (demo is no longer available.)

Note: this demo is currently running in a test environment, so you may experience the occasional hiccup. A production deployment of an application like this would be much more robust.

Unfortunately, the demo is no longer active.

Why a Multimodal App?

“Multimodal Applications” provide access to services and information through different modalities. This application provides access to crime information, including the ability to search for crime incidents by proximity, through a wide range of different client devices include traditional web browsers, handheld devices and PDAs, cell phones and standard land line telephones.

Unlike other applications that are targeted to a specific platform — i.e., applications targeted to a desktop web browser, or to a specific handheld device — the DC Crime Locater can be accessed from a range of different devices. The application is accessible from sophisticated handheld devices like iPhones or G1 phones and from standard home telephones.

This Multimodal paradigm can be used to improve access to other types of government information giving citizens more choices in the devices (and modalities) they will use to consume this information.

Special Thanks!

Serious props need to go to the folks in the Office of the CTO in Washington DC. You don’t see very many government providing the kind of data that the Apps for Democracy challenge is based on. This innovative contest is a fantastic way to get development firms and independent developers (like moi) excited about building powerful applications.

Whether it’s the U.S Census Bureau, the federal Departments of Labor or Commerce, a state health agency, or a local police force, governments are the repositories of vast amount of information. Much of this data has direct relevance for our everyday lives, and can’t be obtained from any other source.

How governments make this information available for public consumption will define the debate on open government for many years to come.

I hope other governments follow DC’s example in putting on this innovative contest.

Advertisements

Apps For Democracy

The District of Columbia is sponsoring an innovative contest to encourage developers to build applications that utilize data published on everything from crime locations to building permits.

The development contest — Apps for Democracy — is currently underway, and concludes on November 12th.

I’ve signed up for this contest and will be submitting an application for consideration — I’ll be building a multimodal application using Voxeo Prophecy and the HAWHAW PHP library. I hope to have it done by the end of the week and will post details here, and probably a video demonstrating how the app works.

Stay tuned…

Demystifying VoiceXML Subdialogs

Note – this post demonstrates the use of VoiceXML subdialogs. The examples below were tested on the Voxeo Prophecy platform. To download the Prophecy software and run these examples locally, go to http://www.voxeo.com/prophecy/.

What are Subdialogs?

Subdialogs are a powerful, but often misunderstood, part of the VoiceXML specification that can be used to create reusable components for telephone applications.

The official W3C VoiceXML specification defines subdialogs thusly:

A subdialog is like a function call, in that it provides a mechanism for invoking a new interaction, and returning to the original form. Variable instances, grammars, and state information are saved and are available upon returning to the calling document. Subdialogs can be used, for example, to create a confirmation sequence that may require a database query; to create a set of components that may be shared among documents in a single application; or to create a reusable library of dialogs shared among many applications.

One of the most confusing aspects of subdialogs is that they run in a completely separate execution context from the dialog that invokes them (the parent dialog). However, once developers get over this conceptual hurdle, the real power of subdialogs becomes apparent.

Fun with Subdialogs

One of the things I like most about subdialogs is their reusability. I often find myself in situations where I need to collect input from a caller in several steps that are generally the same (i.e., a series of digits), but each has a specific validation requirement.

For example, in order to process a credit card payment there are several pieces of information that need to be obtained form a caller – credit card number, CVV number, expiration date, etc. All have the same common characteristic that they are a series of digits, but all have unique verification requirements. Valid credit card numbers have specific lengths and must pass a “mod 10” check. CVV numbers are specific lengths for different card types.

As with a typical function call in any programming language, parameters can be passed into a VoiceXML subdialog when it is invoked. These parameters often take the form of a string of text to be read out to the caller, or a number that is used to count actions. However, we also have the option of passing more complex data types into a subdialog call

We can pass JavaScript arrays and custom object into a subdialog, or we can pass some of the native object types in JavaScript. For example, every function that is declared in JavaScript is also an instance of the JavaScript Function Object. So a JavaScript function that is declared in a parent dialog can be passed into a subdialog as a parameter.

For example, consider the following simple subdialog:

<form id=”S_1″>

<!– Parameters passed into subdialog –>
<var name=”myPrompt” />
<var name=”myFunction” />

<catch event=”noinput nomatch”>
  <prompt>That was not valid input. Try again.</prompt>
  <reprompt/>
</catch>

<field name=”getInput” type=”digits”>
 <prompt><value expr=”myPrompt”/></prompt>
  <filled>
    <if cond=”myFunction(getInput)”>
     <return namelist=”getInput”/>
    <else/>
     <clear/>
     <throw event=”nomatch”/>
    </if>
  </filled>
</field>

This subdialog accepts two parameters – a prompt that is read out to the caller, and a function that is used to validate the input. The conditional logic in the <filled> block assumes that the function returns a boolean (true/false).

This same subdialog structure can be used to collect input that meets a wide range of validation criteria. To use this subdialog to collect a 5-digit zip code, we would set the parameters as follows:

// JavaScript function to determine length of a string variable
function isFive(x) {
  if (x.length == 5 ) {
    return true;
  }
return false;
}

<param name=”myPrompt” expr=”‘Please enter your five digit zip code.'”/>
<param name=”myFunction” expr=”isFive”/>

To use this subdialog to collect and validate a credit card numbers, we would set the parameters as follows:

// JavaScript function to perform a mod 10 check
function mod10Check(x) {
    // logic of mod 10 check
    return true;
}
return false;
}

<param name=”myPrompt” expr=”‘Please enter your credit card number.'”/>
<param name=”myFunction” expr=”mod10Check”/>

A sample VoiceXML document, demonstrating how this same basic subdialog can be used to collect different kinds of input can be found here.

As this discussion shows, subdialogs are a tremendously powerful tool that can enhance the reusability of code and reduce the maintenance requirements of telephone applications. So, if you find yourself in a situation where you need to collect the same type of input from a caller several times during a call flow, take a look at subdialogs.

Their power and reusability have the potential to make your life a lot easier.