Where the Rubber Hits the Road: What makes technology effective?

Facilitated by Rob Miller and Nick Grossman, Open Planning Project

Technology is a means, not an end. Some technological initiatives bear tangible fruit; the real world impact of the tools is obvious and significant. In other cases, the impact is less dramatic and more subtle, but still evident. And in still other cases, the impact is minimal at best. Looking at examples of each case, we will explore what makes technology effective (or not!) for on-the-ground campaigns.

Agenda

• Introductions
  • "Smoke and donuts apps"
• Shameless plug portion of the talk
  • The Open Planning Project (TOPP). Produce tools that effect real social change.
    • How people inhabit cities
    • Urban planning, transporation policy. People occupying public space, not just moving cars around
    • What we have worked on
      • Open source GIS software, OpenGeo, OpenLayers, GeoServer (http://opengeo.org)
      • Livable Streets movement. Livablestreets.com. Featuring tech projects that work towards the livable streets movement. Streetfilms.
      • http://openplans.org. Open source google / yahoo groups. File sharing, etc. Resource management.
      • We're a software shop, we're a media lab, and we're a consultancy
    • What we want to work on
      • Open source software for government
      • Software for urban policy, tranportation
      • Education. Teacher resources, Parent organizing. New blog called Gotham Schools

TOPP's Experience

• We're going to kick it off and talk about some success stories and some less-than-successes
• A big success was Uncivil Servants http://uncivilservants.org
  • The police don't enforce parking violations by civil servants
  • An organization (Transportation Alternatives -- http://transalt.org) already had a big campaign going. They just wanted a web component.
    • Instead of making something from scratch, we found someone who already was doing something similar (bike lane violations at http://mybikelane.com), and worked with them to adapt their code.
  • The project got a LOT of attention
    • NYPD went crazy and threatened the project lead
    • But users also posted a lot right away, it got a lot of press
    • In the end, the mayor's office changed the policy around how permits were issued
    • Why it worked
      • Worked with someone that already had a proven idea
      • Reused code
      • Narrow focus and purpose
• Streetsblog / Livable Streets Network
  • There are a lot of people who care about pedestrian & bike issues and livable communities
  • The films were a big success -- sent a team to Colombia to study other examples of best practices in urban policy. It convinced Gavin Newsome to push for [Ciclovia] in SF
  • Most of the money has come from one main investor, along with other partners -- foundations, non-profits, individual investors
• Streetswiki
  • Medium-sized success
  • Allow people to talk about ideas and structures related to urban planning & transportation planning
  • Promotional event: Wikis take manhattan
    • Teamed up with wikipedia to go take pictures for stories on wikipedia and streetswiki that didn't have pictures
• OpenPlans
  • It's getting used, but mostly in the Plone community rather than the intended use of community activists
  • Underlying open source tool has gotten some adoption -- http://indy.gr and http://openesf.net
  • Why didn't it take off as intended:
    • The original mission was a bit vague
    • The internal team had tension around it being a service for a general audience or for the open source community
    • The tech stack was a little complicated and scared off some people
    • Not enough of a users-first development model
    • Not enough energy on community management

Discussion

• User testing
  • How important is it to make it slick and easy to use? Or how important is it to just get
• The tech-heavy projects are sometimes sexy for developers, and the user-focused projects sometimes aren't sexy from the tech perspective
• Online community
  • An after school program in California (California Voices). We tried to have a youth summit, all the students came together, then would go back and participate in an oline community. We shifted into more of an offline community with an online component
  • A standalone online project failed, but as a companion to an offline community it thrived
  • Creating physical spaces
  • Starting out with a small pilot. Communities forming without a tech infrastructure, and working on the tech as we go
    • There are a lot of risks doing it that way
    • Be weary of changing technology on people once they have established a community
      • Top-down approach. "we're just going to rebuild the site, users be damned"
      • Wiki into more process oriented tools, people
      • People end up being more attached to things that are less usable, because they invested a lot of time in learning it
  • One org tried to make a test group by selecting people from within the organization, didn't have a good idea of their audience
  • A problem of the people making the decisions not understanding the technology (coming from a print background for example)
  • Is it better to do a small group of representative users? Or targeting a specific need that everyone has
    • When you start with a small group and meet a small groups needs you already have a success. You could stop right there and at least someone would be happy
• Yahoo Live
  • They just shut it down, some people are heartbroken
  • The reason it died was because instead of working on features that would restrict how people could use it.
    • They were spec'ing their user base out
    • Work towards positive use rather than legislating against negative use
      • Don't build deterrents to homeless people being in parks, make the parks a better place for everyone
• A news service called Joomla Connect
  • Instead of letting people post to a site, we aggragated news from other peoples sites. We could control was a part of the aggragation
  • It worked because people aren't going to post crap on their own site, but they are perfectly willing to post crap on other people's sites. Delegating the moderation. People have to have ownership over their content
• Appearance of activity
  • The home page doesn't have anything, but the mailing list and the forum were full of activity
  • A feed aggregator to the home page allowed people to see the activity
• Multimedia content
  • There are a lot of Plone people making media, but posting to their own site. So we made a site for people that allows them to get their media to a wider audience
• Twittering the vote
  • crowd-sourced election monitoring
  • They got the whole thing working in one day
• The failure was not in failing to implement the right technology, but just failing to recognize what was needed from the technology.
• It's easy to forget that what we're here to do is server people, and the closer you can be to the people doing the work the more effective you can be

Take aways

• Making the software connect to the real world and real people from the start. Vetting priorities with the community, and have a community management process from the very beginning
• Work towards advocating positive use rather than legislating against negative use
• Be weary of changing technology on people. People end up being more attached to things that are less usable, because they invested a lot of time in learning it
• Technology projects that had a physical component and have tight focus / small scope are more successful
• The more ownership people have the less likely they are to abuse it