Lesson 1: Great gov2 project combine services that normal people care about (people who don’t care about transparency) with transparency. People care about their roads. But you need transparency to get them the site they actually want.

Lesson 2: First rule of Government Data Mashers Club is that you do not talk about Government Data Mashers Club in front of your users. Tom said he’s a big fan of structured data, but we should be cautious about presenting a site that’s About Data. The public needs and wants “is my politician any good?”, “are my streets okay?”, etc. This takes lots of data but you don’t have to lecture about how lucky they are.

Lesson 3: Successful sites have simple description of what they do. Fix My Street “fixes your streets”.

Lesson 4: Can help Government reform by bolting interfaces onto the platform of Government before the platform has been fully built. Councils want a standard API to feed data into Fix My Street, but if MySociety had begun by convening a meeting we’d still be waiting.

Quote from Clay Johnson: “Coding is quicker than consensus.”

Two appeals. First, as technologist and second as pretend US citizen.

Build FixMyStreet in USA. Citizens deserve services that hide the splinter of federalism. Hard because of federalism, but that’s why you should do it. And when you succeed, you have a simple example that gives legitimacy to other things.

Want Government in US to be braver in UK. Act as though it is genuinely more important to bring citizens together in stronger civil society than it is to manage a bad press day. Write Your MP creates opportunity to write back to users, let users collaborate and talk, but politicians won’t do it because they’re afraid of what the citizens might say! Because it might be a bad news day. “You can’t use our roads to go to political meetings because it might be a bad news day” would lead to revolution.

He gave two examples: Apps for Democracy vs the LA Times Wikitorial. Apps for Democracy was a success, the Wikitorial not. Wikitorial was Times putting editorial online and saying “improve this like Wikipedia does”. It lead to: arguments, flamewars, spam, porn, goatse.

He talked about social agreements by talking about a study of Israeli daycare pickup times and the effects of fining parents who were late to pick up kids: the rate of late pickups increased, and didn’t return to normal after the fines went away.

This is because fines broke the incomplete social agreement. The incentives of the market aren’t something you can casually add to an existing social relationship. You miss someone’s birthday, you can send flowers but not the amount of money the flowers would have cost.

Wikitorial killed creativity possibilities. LA Times press releases gave them no space to adapt, no room to learn.

Apps for Democracy did these well: only offered data sets, knew motivations of hacker participants would be what drove them forward, didn’t take credit for apps until after they saw what happened.

1) Contract with users has to be complete enough to get the users interested but not so complete that it depresses them.

2) Give the users space to participate, don’t predict what they do.

3) In the domain of collaborative production, it is Heisenberg’s Press Release: the more you take credit in advance for future success, the less likely the success will be.

It’s not hard because of the technology, it’s hard because of the people. Users never do what the designers want or expect. That’s if it’s a success. Failure is if nobody uses it at all. Successful applications create surprises.

Make an incomplete contract that invites the user in, lets them know that they want to, and you want to help them, make those surprises as surprising as possible.

The big takeway for me was that while administrations change every four or eight years, your open government initiative doesn’t have to die with the next regime. If you build something that citizens will get addicted to, the citizens won’t let the pols break it.

Apps for America, contest around data.gov. This is their second contest. (I apologise for not linking here, I’m blogging on the run at the conf–Google will find you the projects I mention here)

Rule: any entry needs to be open source. OSI-approved license, just needs to be open source. Second rule: any feed from data.gov, even data.gov itself.

Prizes: $10k first prize, $5k second, $2500 third. And a $2500 visualization special category, and ten honourable mentions at $500 apiece.

47 open source projects were created, most still being maintained.

Local Spending: HTML5 geolocation to tell you what spending from USA Spending.gov is happening in the user’s area. Did the same with recovery.gov money.

Budget: takes the federal government and makes it a bit more comprehensible. “That’s enough to buy 4M mid-size cars at sticker price”. Gives the top-level line-items for the depts, drill down, graphs and human-comprehensible info.

FBI Fugitive Concentration

Fly On Time.us : Data from FAA, probability analysis to tell you how likely your flight is to be delayed, even before it’s announced that it’s delayed.

QuakeSpotter: desktop app showing you all the earthquakes happened over last few days. Can click and search Twitter around the earthquake to see people talking about it.

Data.gov Timeline: charts data from data.gov over time. So can play unemployment data over time, mash up data sets, drill into specific states.

Quake Alert: Facebook alerts when your friends have been in an earthquake.

Finalists

GovPulse came in second. Completely visualizes and makes the Federal Register readable. Subscribe to different agencies in RSS. Geolocates.

This We Know: takes all the federal data for a locatable place and tells you about the neighbourhood.

Data Masher (winner): take two datasets from data.gov and mash them together, compare, graph.