Crowdsourcing Urban Service locations (from Textizen)

One of the potential uses (and, frankly, a pretty low-hanging fruit) for online public engagement is to figure out where the things that people use or benefit from ought to be placed.  Engineers and urban designers spend huge amounts of time trying to prognosticate where features like street trees or bike racks should be located…of course, what they are trying to do is to place them in the most useful locations, so that lots of people use them and are happy with the whole deal.

But, as our history of urban design messes worldwide shows, the experts often don’t get it right.  As a result, it makes sense that an important element of this process should be understanding what regular users think would be useful.  That’s not rocket science, but harder than it looks: when you rely on paper maps at a meeting and ask people to mark where they think specific things should happen, very often they read the map wrong.  Paper maps are harder for most people to connect to reality than most planners would like to admit.

This article outlines a great collaboration between OpenPlans, whose crowdsource mapping platform has been discussed here before, and Textizen.  The goal of this project is to identify  the best locations for a new network of bike share corrals — an item that can wildly exceed or wildly miss its expectations, depending on where it’s located.

You can read the brief description of the project here, but what I want to call out to you are three elements:

1) This approach makes the location recommending process about as frictionless as possible.  There’s about 100 potential pre-vetted options available (so no risk that the highest vote-getter will turn out to be logistically impossible), people send a text  when they are in a location that they think would work well, and their input pops onto a map.  No trying to figure out the cross street or which way is north or whether I am on this corner or that corner.  And you don’t have to try to remember where you were when you get back to your computer.  Or whether your data plan is about used up (assuming you had one, which you might not).  Just send a text.  Easy cheesy.

2) Note the interface between the online feedback and the in-person, visual experience.  The murals are central to the success of the project, not only because they mark those previously-vetted locations,

From Textizen. Image via temple_sea on Instagram

but because they cut through the environment’s clutter and grab the potential user’s attention.  I am often surprised at how often I still have to say this: you can have the most whiz-bang online tech in the world, but if you don’t connect it to people’s lived experience, get their attention, you will have wasted your effort.  The offline marketing is every bit as important as the onlineexperience.

3)Both of these platforms were built as Open Source, which means that the specific code is available to anyone who wants to use it.  You can copy pieces of the code, make your own revisions on your own version, and use that to build something that can work seamlessly with the original application.

The benefits of open source in civic technology at this stage of the development of this industry are exceptional.  With conventional applications, like many of those in the online public engagement space today, the programming that drives how it works and what it does is “closed” — that is, it’s proprietary to the business.  This is a pretty typical way of doing business, but it means that most of these apps are, as it were, rigid — they can’t be substantially changed or adapted, and getting one to work in conjunction with another is a clunky process, at best.  I’ve driven those types of collaborations as a consultant, and the logistical barriers result in a product that doesn’t work anywhere as well as it should.   In one case, the only solution was two separate web sites “skinned” to look like each other (and that was only feasible because one provider had the flexibility to match its user interface to the other, which could not significantly change).  But share information between them?  Use inputs into one program to populate a map in another?  Impossible.  Can’t be done.

OpenPlans has been a strong advocate for open source civic technology, and Textizen got its start in Code for America, for which open source is a core value and a characteristic of pretty much every CfA initiative that I know of.  Because they are both open source, making these two work together — sending Textizen inputs directly into the OpenPlans maps — could be done with a minimum of fuss.  Both companies could see easily what needed to happen on both sides to make that happen, so that it became (I would guess) a relatively straightforward programming exercise.  Instead of settling for a clunky, off-putting experience, the open source paradigm allowed both companies to focus on the main goal: making the user experience as engaging and frictionless as possible.

Good job, guys!