Indaba fieldwork platform: demo, design concepts and lessons learned

From DevSummit
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Facilitated by Jonathan Eyler-Werve, Global Integrity

Session Description

An introduction to the Indaba fieldwork platform, which helps distributed teams to create data and reporting through a browser-based database. Indaba is being developed by a coalition of international NGOs lead by Global Integrity. Currently deployed with researchers in 34 countries, Indaba integrates elements of relationship management, project management and knowledge management into a simple but powerful workflow management system. Indaba aims to accelerate efforts to create new public data in open, sharable formats.

(Note: this is largely previewed at http://getindaba.org/about/indaba-demo/)

Session Notes

Background on Global Integrity and Indaba

Decided not to open field offices but were angry with how NGOs were run, specifically in how they were reporting how they are run. Push to be more accountable with aid and use metrics. A lot of data was not inclusive or accurate. Saw need for better metrics. Went out and talked with people local and on the ground, but needed technology hat was extremely scalable to manage large distributed network.

What kind of content are you collecting?

A lot of everything. Journalism content – score cards, policy analysis. Requires structured database responses, not going to work to send Word docs back and forth. Needed to rebuild old system built in ColdFusion. Started over and decided to also make available to other organizations and provide something of a lot better quality.

Started out by doing audience research and went out into field to learn more about people doing work on the ground. A lot of people work in newsrooms from internet cafes. Jonathan flipped through several photos of people interviewed. All users were hyperconnected with busy/messy. This is the demographic. Wanted to deliver workspace that was simple, easy, clear, low-hassle to get into, do useful work, get out of. Had to setup in very structured way to give very contextual, personalized experience so people can login to get individual assignments, relevant documents, status of assignments, and participate in a custom, role-based workflow to publish things in a way that is lightweight way for managers but still scalable for a larger network.

Have to think about three things:

  1. relationships (between people, workflows)
  2. knowledge management
  3. accountability (are people actually using system).

Big decision was that management of workflow rules was lacking in available content management systems. Goals have to happen in sequence, but they might branch and merge. Ex: Payment → Author → Editor 1 → Back to Author → Editor 1 → Editor 2 → Peer reviewer 1, 2, 3. Rules/business logic than determines what happens to content in different scenarios (ex: If 2 out of 3 peer reviewers complete reviews, then content gets published).

Big database (MySQL) under whole system for user management and content. Lightweight set of admin screens built in PHP. Java for all actions. Publisher component is set of data extractors that publishes to API (probably Java) . Can export to text, spreadsheets or use widgets/API. Data model is under everything (big database of stuff) so as the project grows, services and distribution options will grow as well over time.

Jonathan shows a demo of the Indaba manager view. Status bar shows where content is in workflow/process so it can be monitored/manages, which gives visibility into the workflow and checkpoints for greater accountability.

They are trying to optimize for low-bandwidth scenarios. Queues show lists of assignments/tasks. Does not necessarily handle the whole task within Indaba, but manages “gates” during workflow process that can be crippling when you scale them.

Currently organizations are getting most of this work done by emailing Word documents back and forth and "doing all sorts of insane hellish things". Asked how do they collect quantitative data? Most do it in Word docs because the fieldworkers are so overloaded with tools already that it's not feasible to add another. Must make system easy and usable for people in the field.

System protocol/standard for user privacy is that everything that goes into the system is intended to be published. Users can use pseudonyms to protect their identity.

Item view shows contextual instructions, discussions, scorecard with questions and answers. Ex of question: Can citizens freely use the internet? Highly valuable data that costs about $10k to produce. Used to have to start field office, get equipment, security staff, etc to be able to then hire a journalist --> Indaba is much less expensive and more efficient.

How do they find reporters? Look at organizations who prescreen/give awards, ask them for referrals, cross-reference. Biggest pain point addressed is emailing content back and forth.

List of things for advice/help:

  • Has anyone ever used widgets for content delivery?
  • How to journey toward openness? Ideally organizations would share a central database as opposed to a distributed model like Wordpress.org, Ushahidi, etc. How to avoid a bunch of forked databases? How to get critical mass so people will participate in a community?

We discussed some issues of data protection among nonprofits who see data as their asset. Hard to get them to accept open source, shared database model.

Indaba is being implemented for 5 projects: Carter Center, Global Integrity, International Budget Partnership, Revenue Watch

Questions are shared across organizations, can match data quickly. Can do some pretty powerful queries to get new data.

Project will take 6 months to run end to end to get Indaba up and running for the 5 orgs mentioned above. 5 full-time employees, publish a lot of content (equivalent of entire Harry Potter series per month). About $300k invested to build so far. Each project launching on Indaba so far is large. Trying to share total cost of ownership. Looking to scale gradually.

Helps that a lot of content in these use cases is intended to be published.

Potentially a lot of overlap or beneficial parallels in collected data.

Hoping to attract users because they can opt-in to include a widget on their site and get traffic.

For the future, looking at the example of Walking Papers - how they fill in OpenStreetMap. Some kind of implementation like this for forms/questionnaires/scorecards would be really really cool.