By Friedrich Lindenberg
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 Inteligentein Chile develop services that aim to improve interactions between government and citizens.
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.
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.
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.
Image (C) Stefan Gehrke, CC BY 3.
Get more stuff like this
Subscribe to our mailing list and get interesting stuff and updates to your email inbox.