This article is cross-posted from IJnet.org. Above: ICFJ #CodeCamp in Bellagio, Italy. 

While many in journalism are searching for ways to harness their readers’ expertise and to use data to tell compelling stories, technologists and NGOs who build civic technologies around the world are asking some of the same questions. Organizations like the UK’s MySociety, US-based Code for America, Code for South Africa or Fundacion Ciudadano Inteligente in Chile develop services that aim to improve interactions between government and citizens. RELATED ARTICLE

“Meet the 2013 Knight-Mozilla OpenNews Fellows” on Knight Blog

Both media organizations and NGOs are exploring the development of similar services, such as initiatives to analyze data from their countries’ legislatures, tools that facilitate writing and publishing requests for information from government, and databases that help patients find the cheapest medicine. While in some cases such NGOs provide only raw data without much analysis, other initiatives, like Homicide Watch DC, blur the lines between civic technology and journalism.

Over the last few years, I’ve worked on both sides, as a developer of civic applications like OpenSpending and Adhocracy, and as a Knight-Mozilla fellow inside Spiegel Online, a German news organization. From those experiences, I believe that it would be interesting for journalists to have a look at the lessons learned by civic technologists as they experiment with online strategies for citizen engagement, data-driven service delivery and government accountability.

At the same time, civic technology initiatives are driven by many different groups in many different countries. Too often, a group will needlessly re-invent or replicate concepts that have already been explored and tested in another place, without the groups sharing experiences (and working software). More than that, there’s too little sharing on what the success factors for civic technology are — what types of interactions work, how information can be made relevant to citizens and how to make sure services meet the needs of their users.

To capture these lessons, a team at the ICFJ CodeCamp in Bellagio in May chose to create Civic Patterns, a pattern language for civic technology. (I attended CodeCamp as part of my ICFJ Knight International Journalism Fellowship.)

The idea for Civic Patterns stems from a 1977 book by architect Christopher Alexander, A Pattern Language. Alexander sets out to conceptualize strategies used in the design of houses, towns and cities. His patterns, with names such as “Light on Two Sides of Every Room,” “Waist-High Shelf” or “Ring Roads” were aimed to let anyone – not just architects and planners – join conversations about the structure of social spaces.

In the mid-nineties, the adoption of the idea of pattern languages into software development actually inspired the creation of the first wiki, the Portland Pattern Repository. In a similar vein, Civic Patterns attempts to become a collaboratively developed language of strategies for citizen engagement, community coordination and service design on the web.

The project focuses on four themes: Community, Engagement, Delivery and Government. Community captures ideas such as No Social Networks – don’t try to rebuild Facebook for a specific topic. Instead, think about how you can interact with existing platforms. Even more, Single User Mode requires that your service needs to make sense even for a single person using it on his or her own.

Engagement looks at designing activity. For example, the notion of Push, Don’t Pull recommends sending out email notifications instead of expecting users to visit your service regularly, while the Don’t Educate pattern says that a service should not try to educate its users – but rather remove the need for them to be educated. For example, instead of teaching people the legal aspects of submitting freedom of information requests, a platform can just fill in the legalese and advise users on their options as they step through the process.

Delivery relates to attracting and retaining people who use your service. For those of us who like ambitious projects, Don’t Boil the Ocean is a reminder to limit a service’s scope, while the Kill Switch is a failure condition in adoption that has been defined before the project is kicked off.

The last category, Government, has patterns for dealing with large bureaucracies. Approaches like Ask Forgiveness Not Permission or Make Government Your User are likely to apply to media companies and newsrooms as well as to the state.

Civic Patterns is the beginnings of a language for those working to design civic technology. More than that, however, it could be a common vocabulary for all those who want to make apps for the public good – a group that certainly includes journalists and news technologists. Of course, this work is by no means finished. Instead – like any language – it is itself a collaborative project, where anyone is invited to suggest changes and additions.

Once we have a common language, we might realize that we’ve been working on the same problem all along.

Friedrich Lindenberg is an ICFJ Knight International Journalism Fellow who works with journalists and watchdog organizations to develop data resources and investigative tools.