Open311 DevCamp foll ... / Philip Ashlock

Open311 Discuss archive 2009 11 Open311 DevCamp foll ... / Philip Ashlock

Open311 DevCamp follow-up

From: philipashlock

Subject: Open311 DevCamp follow-up

Date: Nov 09, 2009 06:12 PM

This follow-up is long overdue, but progress has certainly not slowed.
My initial DevCamp follow-up
<http://open311.org/2009/10/open311-devcamp/> 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
<http://www.viddler.com/search/global/?searchString=311DevCamp>. The IRC
log is available here
<http://wiki.open311.org/DevCamp_IRC_Log_2009-10-24>. Some of the main
wiki pages created are:

* Documentation of existing 311 systems in cities
<http://wiki.open311.org/Main_Page#311_Information_by_City>
(Cities, please edit these. Thanks adding yours Toronto!)
* Creating a universal Open311 API
<http://wiki.open311.org/Open311.org_Draft_Spec>
* Pitching cities on Open311 <http://wiki.open311.org/Open311Pitch>
* Usage and analysis ideas for 311 data
<http://wiki.open311.org/Usage_and_analysis_ideas>

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 those who prefer not to be on the mailing list, I can send out an
announcement email about once a month. If you would like to remain on
the announcement list instead or if you know of someone who would be
better suited to receive these emails please let me know. You received
this email because you are on my contact list for the Open311 effort
(most likely you are someone who's listed on
http://open311.eventbrite.com). Please let me know if you would no
longer like to receive emails on this subject and also please let me
know if you would prefer that I not share your email address with the
other people on this list. I don't want to make anyone's email address
publicly available, but I would like to share contacts within the group
that registered for or expressed interest in the Open311 DevCamp.

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
<http://www.nyc.gov/apps/311/allServices.htm?requestType=Navigation&intentId=E9E66310-8137-11DE-8E9F-96DAE110FEB8>.
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 <http://fixcity.org/>.

*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 TOPPLabs blog today
<http://topplabs.org/civichacker/2009/11/text-to-voice/#comments>). 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 mention at the DevCamp. It turns out that on the
day before the event, Mark Headd wrote an excellent post about this on
the Vox Populi blog: http://www.voiceingov.org/blog/?p=1246 I know Troy
from CloudVox participated in the DevCamp remotely, so maybe he has more
to say on this. Ribbit just opened up their voice/web-api service and
there are already some cool demos
<http://twitter.com/philipashlock/status/5457291803> 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:
o Simple and easily accessible (minimum fields required,
status: "submitted")
o Crowdsourced validation (city requirements, status: "validated")
* Adapter to translate existing systems for Open311 web APIs
* Existing CRM/311 system
* Government

*Open source implementations*
There are at least three open source service request web apps
<http://wiki.open311.org/Main_Page#Open_Source> that are available for
anyone to implement any draft of an API spec.

* FixMyStreet <http://www.fixmystreet.com/> (source code
<https://secure.mysociety.org/cvstrac/dir?d=mysociety/services/TilMa>)
* FixMyStreet.ca <http://www.fixmystreet.ca/> (Django source code
<http://github.com/visiblegovernment/django-fixmystreet>)
* GeoTrac <http://geotrac.demo.topplabs.org/> (installation and
source code <https://projects.openplans.org/GeoTrac/wiki/Install>

*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
<http://wiki.open311.org/Open311.org_Draft_Spec> page and I've started
sketching out my interpretation of a possible schema in JSON on that
discussion page <http://wiki.open311.org/Talk:Open311.org_Draft_Spec>.
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 <http://apps.sfgov.org/Open311API/> 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.

*Action Items*

1. Get everyone on the mailing list
2. Continued coordination among those working directly with API
implementations.
3. 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. Please
let me know if you have any questions.

Cheers,
Phil

ps. most of the content of this email is in this blog post:
http://open311.org/2009/11/open311-devcamp-follow-up/

--
Philip Ashlock
The Open Planning Project - http://www.openplans.org
phil@... <mailto:phil@...> | @philipashlock
<http://twitter.com/philipashlock> | (360) 389-2741