This follow-up is long overdue, but progress has certainly not slowed. My initial DevCamp follow-up pointed to most of the resources that came out of the event, but I’ll run through them again. The video stream of the DevCamp is available here. The IRC log is available here. Some of the main wiki pages created are:
- Documentation of existing 311 systems in cities (Cities, please edit these. Thanks for adding yours Toronto!)
- Creating a universal Open311 API
- Pitching cities on Open311
- Usage and analysis ideas for 311 data
So again, the main focus is still coordinating a standard API, but this group should also be leveraged for sharing best practices around 311 services in general. Please use the wiki and mailing list to help facilitate better communication between cities and other entities. If you are not already on the mailing list, please subscribe at: http://lists.open311.org/discuss
For a more full follow-up, let me review some of the things that left the strongest impression on me both during and following the DevCamp:
The need for a two-tiered model for submitting service requests
This issue comes up over and over again when one looks at the usability of service request systems currently in place in most cities. The problem is that most existing systems have a very cumbersome process of collecting a required set of fields in order to submit a request. The problem isn’t as apparent when speaking to a call center because the complexity of required fields is often completely curtailed by the operator, but with most on-screen interfaces the complexity of the required fields often makes the system unusable. This was one of the main topics of conversation when discussing a standard API and we couldn’t help but joke about the absurdity of some of the required fields for some service-request types in DC’s 311 API, like the list of available colors to identify an abandoned bike. Dmitry conceded that if an image is attached to a submission it can negate the majority of required fields for many service request types. In some cases, the problem is just identifying the service request type from the beginning. For example, try to navigate the ontology to report a pothole in NYC’s 311 list of request types. So the problem remains, how do you provide a user interface that makes it extremeley easy for someone to submit a request without too many required fields or a complex ontology of service request types? I think the answer is a two-tiered approach. First you allow submissions with the most basic core set of fields. The submissions then sit in a public holding bay where you or anyone else, including a city worker, can review the submission and help complete all the required fields. This two-tiered approach is the process we are currently using for our FixCity Bike Racks project.
The value of improved inter-agency communications
When I talk about the value of opening and standardizing 311 systems, I tend to look at it from outside government and focus on the benefits of better connecting citizens and government. However, many of the people at the DevCamp from within city governments mentioned the value of improving inter-agency communications and I think that’s really important to keep it mind, so I’ll be sure to emphasize that in the future.
The cost of SMS and the value of voice
Something I tried to say whenever discussion of Twitter integration came up was that if you’re discussing short-from submissions, then you should also be talking about SMS integration. Since SMS provides much wider coverage to a much wider demographic than Twitter, I thought this was an important accessibility (and digital-divide) issue to raise. Having said that, I was reminded of how expensive SMS is for services to support (and there’s some discussion of this on the TOPP Labs blog today). The far more universal and far cheaper medium is voice (phone calls) and obviously that is how the vast majority of 311 communications occur. As I mentioned in my Gov 2.0 talk, we are now at a point where voice can seamlessly integrate with web APIs. I don’t think this is something that received nearly enough attention at the DevCamp. It turns out that on the day before the event, Mark Headd wrote an excellent post about voice and web APIs for 311 on the Vox Populi blog. I know Troy Davis from CloudVox participated in the DevCamp remotely, so maybe he has more to say on this as well. Ribbit just opened up their voice/web-api service and there are already some cool demos starting to come out of that.
The layers of the Open311 model:
This rough outline is the result of further considering how the different parts of the Open311 model must to fit together
- End user
- Client application
- Open311 API – decentralized read/write web APIs. 2 step submission:
- Simple and easily accessible (minimum fields required, status: “submitted”)
- Crowdsourced validation (city requirements, status: “validated”)
- Adapter to translate existing systems for Open311 web APIs
- Existing CRM/311 system
Open source implementations
There are at least three open source service request web apps that are available for anyone to implement a draft API spec.
- FixMyStreet (source code)
- FixMyStreet.ca (Django source code)
- GeoTrac (installation and source code)
Developing the Open311 Spec and API
An abstract and some of the terminology relating to an API was put into the wiki on the Open311.org Draft Spec page and I’ve started sketching out my interpretation of a possible schema in JSON on that discussion page. Syntax highlighting is enabled on the wiki if people want to put in snippets of code or structured data to discuss.
We should continue to help coordinate the details of the spec, but I think this should be done simultaneously with iterative reference implementations. I think slight variations of APIs and schema like this will emerge both experimentally and in-production. San Francisco’s 311 API will be a useful reference point since it will represent the second city (after DC) to provide a read/write API and the first real opportunity to consider interoperability. With continued coordination we can see what works best.
- Get everyone on the mailing list
- Continued coordination among those working directly with API implementations.
- Release reference implementations, client apps, and web API adapters for existing systems
So there’s a bit of a brain dump for now. I look forward to hearing your feedback and continued coordination on the mailing list and wiki.