Prowling for NY Senate Bill Status Updates

Ever since I started working on a multi-modal application for looking up the status of a bill in the New York State Legislature using the fabulous Open Leg API from the NY Senate, I’ve been thinking about ways to enable “subscriptions.”

By subscriptions, I mean allowing people to specify which bill (or bills) they are interested in and having a notice sent to them – using whatever channel they deem desirable – when the status of the bill changes. I’ve thought about how this would work for a while now, but haven’t had the time I need to sit down and actually build out the required pieces. A robust subscription framework for a service like this will require some way for people to specify their preferences (which bills they want to subscribe to, what channels they want to receive notice on, etc.) and probably some sort of process that checks for bill status updates at regular intervals and launches notices to subscribers. While not overly complex, these pieces will require more time than I have right now.

In the interim, however, I’ve been meaning to try out Prowl. Prowl is an application that lets users set up notifications (typically from their Mac or PC) that get pushed to their iPhone or iPod Touch. The Prowl client doesn’t poll a service or RSS feed, but instead receives a push when a noticeable event occurs.

The Prowl service also has an API that makes building custom apps and script that can send Prowl notices quick and easy. Since there is an RSS feed from the NY Senate that provides information on bill status updates, I thought it would be interesting to put together a quick Prowl API script that parses this RSS feed and gets the latest bill updates – it will then send a Prowl notification if a bill the user wants to track has been updated.

The sample script I worte uses the very handy ProwlPHP class library and can be invoked from the command line. Or, you can set up a cron job to check if a bill status has changed at regular intervals.

Here is the script (admittedly rudimentary, but it gets the job done).

And here is how you can use it to get Prowl notices sent to your iPhone or iPod Touch when the status of a bill you are interested in changes.

  1. Install the Prowl Application on your iPhone or iPod Touch and set up an account.
  2. Log into your new Prowl account and go to Settings. Generate an API key to use when invoking the above script.
  3. Download and install the ProwlPHP class library. Modify the billProwl.php script to ensure the require() statement matches your download location.


You invoke the script by passing in the number of the bill you want to subscribe to and your API Key. See example below.

php billProwl.php S6246 your_prowl_api_key

You can also set up a cron job to check at regular intervals to see if the status of a bill has changed. The following cron entry will check every five minutes to see if bill S6246 is listed in the RSS feed for recent bill updates. If it is, it will send a Prowl notice. To keep things simple, we’ll just send any output (i.e., if there is an error when the script is invoked) to the bit bucket. If this were anything but a demo script, we would log any errors to a log file for follow up.

*/5 * * * * php billProwl.php S6246 your_prowl_api_key > /dev/null 2>&1

When I eventually have enough time to build out notifications for my NY State bill status application, I will most likely add a Prowl channel. It’s just one more way that citizens can get information from their state government on bills that they have an interest in.

Coming Full Circle on 311

Tomorrow in New York City, developers, project managers, public policy specialists and others will come together to discuss an open standard specification for 311 services. One of the primary motivators for this discussion is the work that has been done by the District of Columbia which has deployed an open API for reporting 311 requests.

The idea behind the Open311 project is that both citizens and government are better served by having a uniform standard for 311 API’s like the District of Columbia. An open standard will better facilitate the development of applications and services that make submitting 311 requests easier and more convenient for citizens, and more cost effective for governments. From the Open311 website:

Open311 is not meant to refer to a specific app or any one incarnation of 311 services. Instead Open311 intends to be a specification of an open platform for 311 services…Once this core standard is defined, new user interfaces and custom workflows can be created by anyone and shared between cities to provide distributed innovation.

To help understand where 311 service may go because of efforts like Open311, or even more independent efforts to deploy 311 APIs, it helps to understand how 311 services operate today.

311 Today

Most municipal 311 services are centered around a call center operation. The call center is staffed with personnel that a citizen can speak with to report an issue. 311 Call center personnel are trained and typically have a predefined script that they use when interacting with a caller. This script ensures that they collect all required information from the caller and enter it into the 311 system.

Like many call centers, 311 centers may utilize some limited routing logic or an ACD to send a citizen to a specific agent or group of agents based on the issue they want to report. Also, like most call enters, the largest cost component (or certainly one of the big ones) is likely to be labor costs. There are other costs worth noting as well, some of them borne by citizens – like the cost of waiting in queue when all agents are occupied with other callers.

Interestingly, if you look at some of the details of the responses from the DC 311 API, you can see the call center roots of this service pretty clearly.

This is the response from the DC 311 API for the abandoned bicycle service type. You can see that this response shows many of the elements you would expect to see in a call center script, including prompts and the characteristics of the data entry fields the agent would use.

311 Tomorrow?

By deploying a 311 API, municipalities can encourage the development of new applications and different interfaces for submitting 311 service requests. This benefits citizens because there will potentially be more options to use when they need to contact 311. It can benefit governments because it can facilitate the submission of 311 requests without the need for one of the most cont-intensive components – 311 operators. Governments might also benefit from better information when requests are submitted – 311 applications that run on location-aware devices can easily submit geographic coordinates that may be more precise than an address spoken by a person.

A good example of the kind of innovation that can be fostered by deploying 311 APIs is the winner of the most recent round of the Apps for Democracy Contest — Social DC 311 — a combination iPhone/Facebook application.

But with all of the potential for new applications and slick new interfaces for 311 services from the advent of 311 APIs and the potential development of an Open311 standard, there is another (less obvious) platform on which innovative, cutting edge applications can be developed.

The ordinary telephone.

Why Phones Matter

Simply stated, phones matter in providing government services because almost all citizens have them (landline telephone penetration rates are somewhere close to 95 percent nationally, and cell phone penetration rates are at about 85 percent). Moreover, almost all citizens that have them understand how to use them, and have some experience navigating IVR or touch tone menu systems. There is no learning curve to ascend before a service request can be submitted.

Telephones are the most ubiquitous communications device on the planet, and they do not suffer from the uneven distribution rates of other consumer communications products. 311 service was built around the telephone, so its a natural interface for new applications.

As stated above, there are plenty of examples of 311 systems that use some automation through IVR and other technologies to route calls to agents. But, at the end of the routing process, a citizen talks to an agent and gives information about a service request to another human.

There are enormous efficiencies that could be gained by being more aggressive with IVR-based automation. Admittedly, not every call (or every caller) is right for an IVR system – that’s OK. One of the things IVR systems do is help entities more appropriately allocate scarce resources. Citizens that can serve themselves will do so using an IVR. Those that can’t (or won’t) will drop out to an agent and submit their request the old fashioned way. The finite number of agents on hand to take calls get focused on “high need” callers that require human assistance.

Back To The Future

As I stated in a previous post, there has simply never been a more varied and powerful array of tools available for developers to build phone applications than exists today. Open standards and open APIs (like those listed below) have removed the barriers between phone application development and traditional web development. What’s even more exciting is the potential introduced by the increasing ubiquity of VoIP, which is blurring the lines between traditionally telephony and other communications channels.

Governments don’t need expensive proprietary software or hardware, or a team of highly trained developers to build and deploy a high-volume IVR phone application. With choice has come ease of use and downward pressure on costs. Some of the newest and most innovative platforms around for building phone applications are listed below:

Want to build a portable phone app that conforms to open standards from the W3C? VoiceXML and CCXML are your ticket – these standards are supported on a large (and growing) number of platforms.

Want to build an open source solution that leverages your in house skills in PHP or Ruby? Stand up an Asterisk server and get cracking with PHPAGI or Adhearsion.

Need to connect to the PSTN but don’t want to invest in expensive specialized hardware? Call up a VoIP provider and deploy some SIP trunks.

The sea change in telephone application development over the last several years means more developers have the skills and tools to build sophisticated phone applications. It also means that government need not be locked into any one platform or vendor that has unique expertise in phone systems.

As the Open311 dialog moves forward, and as more and more municipalities begin deploying 311 APIs, it will be interesting to see what develops. Whatever awaits those of us that are interested in what is to come, I hope that there will be some phones involved.

Open Gov Data = The New Outsourcing

It’s been a tough few months for old school government IT outsourcing initiatives. Projects in Virginia, Texas and elsewhere are under increased scrutiny, or just plain in trouble.

Over the last year and a 1/2, a handful of forward thinking governments have started to lay the groundwork for a new way of outsourcing IT work to the private sector — releasing public data sets for developers to build useful applications with. This “new school” outsourcing provides a number of benefits over the old method, and focuses governments on what they do better than anyone else — aggregating data and releasing it to the public in highly usable formats.

This new school outsourcing movement is still in its infancy, and while I have heard some complain about the quality of data made available in some places, there is no doubt that this new approach will provide enormous benefits for governments and the citizens they serve.

It will be especially interesting to see what benefits accrue from efforts like Open311, which is focused on developing standards for interfacing with municipal non-emergency services. Big cities, like San Francisco, are jumping on board.

Stay tuned!

Spanish Language Support Enabled for Bill Lookup

I continue to tinker with my application that allows multi-channel access to the NY Senate Open Leg API. This application allows users to obtain bill information and status through a variety of different user agents.

I’ve now added support for Spanish language callers to the telephone interface. I translated all of the prompts using Google’s translation services.

Give it a whirl at (646) 736-2439 – any feedback is welcome.