Indaba is a browser-based software-as-a-service (soon to be open sourced) that allows geographically distributed teams to create, edit, review and publish original content, such as policy scorecards or citizen audits. This content can include text, quantitative data, and uploaded files of any type. It allows for project managers to easily manage workflows of projects and compile research over a variety of data points or units of analysis. Over the last year we have begun working with a much broader range of partners (both internal and external) to conduct research on the platform. We thought this was a good moment to ask what our partners around the world thought about Indaba as a means of conducting research.

Here at Global Integrity, we are constantly using Indaba and training our partners and contributors on its features. We hear both the complements and the “not so pretty” Indaba reactions. So we found the results of these surveys refreshing – even though the projects were different in their scope and nature; the role that Indaba played in supporting their work remained basically the same. Altogether, we received 133 responses from project contributors.

We were pleasantly surprised to learn that 88% of the total respondents thought Indaba worked well, and 94% thought the technical instructions provided by Global Integrity were sufficient in helping them understand how to use the platform. Eight-eight percent of respondents said Indaba was easy to use.

Some of the respondents’ favorite things about Indaba were: “its clean interface,” “being able to scroll down through questions,” “the interaction between different users,” “its flexibility to permit revisions and corrections,” “ability to monitor one’s progress,” “it is a secure platform,” “very straight forward to use/no frustrations or lost work,” “the possibility of saving my work up to the completion of the report and the instant submission of the report upon completion,” “checking progress status to see how far I had to go in any area I was working on,” “the ability to save and come back,” and “it helped me stay organized.”

When asked what was the most challenging thing about using Indaba, our contributors had a variety of responses: “forgetting to save my work and then losing it sometimes,” “finding where I left off,” “navigation could be clearer,” “lack of an overview of all of the [survey] questions – the navigation between questions was a pain and equally frustrating to copy/save information from it,” “it was difficult to jump around for those who don’t necessarily think in linear order,” “the progress and completion markers and deadlines were not clear,” “it was sometimes hard to gauge how close the project was to completion,” “having to be online the whole time,” and “accessing with poor Internet connectivity.”

Overall, we think Indaba is a great platform. It was reassuring to learn that while there are some challenges remaining (which we are fully aware of and addressing in a huge Indaba 2012 upgrade), the majority of the contributors on these two projects thought the system suited their needs.

Thank you to the hundreds of our contributors around the world that provided us with critical feedback. The full results from both surveys can be found here: The State Integrity Investigation and The Global Integrity Report 2011

This post is cross posted on the Global Integrity website here.

– Global Integrity

In plain English, this means that things like system tabs, alerts, and visual prompts can be made fully and seamlessly available in any language to Indaba users based on their language preferences. Users can switch language preferences on the fly.

As a first step to make use of the language support features, we’ve fully translated all 2,000-plus text resources in the system into French so that our colleagues at he Global Integrity office in Cape Town can manage their research teams across Africa in both English and French simultaneously. We look forward to investing in future language set translations in collaboration with other Indaba organizations that need to run their fieldwork in more than one language.

The last piece of the “language puzzle” is coming in the next quarter: the ability to display and interact with survey questions/indicators in more than one language depending on the the user’s preferences. We’re about that work and will keep everyone posted on our progress.

We’ll be posting a video shortly showing how to change your language preference. For now, visit your user profile in Fieldwork Manager (click on your name in the top right), click Edit, and choose either English or French.

In 2011, we validated our hypothesis about what Indaba can offer to a distributed team creating a scorecard, index, or similar data collection project. Our job for 2012 is scale. Big scale. We want more users, more speed, and more great projects coming out.

To do this, we need to make setting up projects faster and easier. Additionally, we’ll address some usability challenges by making incremental tweaks to existing interfaces. We’ll also continue to aim for best practice security, privacy and system reliability. Lastly, we’ll open the source code behind the Indaba website (“IDB Engine”) for public modification and use.

Fixing setup

Our project set-up and configuration tool, Designer, is a bit of a kludge. We knew this going in. Designer is only used by a team of three to four people, the Indaba system admins at Global Integrity. But Designer works — it allows those system admins to be non-tech folks by providing everything they need to create and launch a project through any Web browser; we don’t know PHP and we don’t want to learn it, frankly.

Instead, we focused our money and attention on the Fieldwork Manager, which is used by thousands of people and is working great. What we’ve learned in the last year is that those few system admins are really important to getting projects into the field on time, and we need to help them out. We also want to democratize the project set-up and configuration process by allowing external managers (e.g. people not working at Global Integrity) to participate in those processes if they’d like.

Our solution has a working title of Indaba Control Panel, and it’s an attempt to give project managers more direct input into getting their projects installed. Among the areas we hope to address:

1. Better automation for inviting project contributors onto the platform.
2. Allow project managers to add and modify their “indicators” (survey questions) on Indaba.
3. Allow project managers to add “targets” (the unit of analysis for a project; think countries, cities, clinics, etc) directly to Indaba.
4. Allow project managers to have direct control over who is assigned to each task in their project.

This may not seem like a radical shift, but it’s expanding the pool of people available to contribute to the more labor-intensive aspects of project setup, and it’s creating a user interface framework for more Designer grunt work to be opened up in the future. This framework will eventually allow us — when the time is right — to sunset the existing Designer tool entirely.

The Control Panel has been whiteboarded and should be rolling out this spring and summer. We’re going to be holding Control Panel to the same high standards as Fieldwork Manager, which means we’ll be giving it extensive field testing at Global Integrity before turning it loose on our partners.

There are three other shifts coming that are more conceptual, but important.

First, we want to offer new project managers fewer options. No, that’s not a typo. What we’ve learned from our Early Adopters partners is that complete customization, while fully available on Indaba, is not an optimal starting position. In some cases, the added complexity of massively tweakable workflows, roles, and permissions prevented us from just getting the thing in the field and seeing how it went. We’re learning from the Lean Startup people, and asking what the minimum viable product is for each project. In many cases, we think we can build off the successful projects of 2011 (which did it the hard way, starting from scratch) and offer several field-tested templates for projects. We’ll install the closest match, and tweak things based on actual user experience, rather than abstractions.

Second, testing is too hard. We need to get people playing with the software sooner; it’s the only way to show project managers what exactly is going to happen on their projects. We’re making some backend changes in the upcoming build that will help with this by making it easier to reset a project to an earlier “clean” status while simultaneously providing project managers with a safe environment in Control Panel to test, break, adjust, and then retest their projects.

Lastly, by combining all of the above, we’re starting to think about how an entirely self-serve Indaba offering would look. Among other benefits, it’d give us the possibility of further lowering costs per project. This is a 2013 effort, but we’re excited about how that changes our growth and cost curves: more projects, lower costs, more open data for the world.

Usability updates

Our fieldwork manager is working pretty well, and we’re not going to change much there. We are making some incremental changes in the upcoming build:

1. Better scorecard review tools, allowing managers to send a list of questions about a scorecard to anyone on the project (not just the “author” who originally submitted it), with configurable options — comment only, comment or edit text, or edit everything.
2. Better visibility into workflows — what exactly do those status boxes mean under My Content? More information would help, and we can do that.
3. Better button placement and labels throughout Fieldwork Manager.

Security and stability updates

A number of small fixes are being done to beef up the Indaba backend. We’re very happy with our system stability, and we’d like to keep it that way. We’re also improving our privacy protections for our users. In the pipeline for 2012:

1. Full-time HTTPS for all users.
2. Encryption for all Indaba databases.
3. Better browser compatibility to bring Chrome and Safari up to the same level of functionality as our “official” supported browsers, Firefox and Internet Explorer.
4. Better handling of some system intensive tasks (like sending hundreds of emails) to give users better feedback that the job is in progress and will continue even if they go to a new page.
5. System event tracking to improve bug reporting and resolution.

Open source and Indaba

Indaba was always intended to be an open, inclusive and public interest project, and releasing the source code as free open source software is entirely consistent with that. We haven’t done it yet — this is awkward but true — because we’ve been busy setting up our partners and haven’t gotten around to cleaning up the code for public release. That changes this spring, when we plan to post the IDB Engine on Github under an Affero GPL licence. We’ll update periodically with the latest version.

We don’t expect this to change our software-as-a-service approach. We hope that others can use some or all of this code, and we encourage all kinds of reuse. For us, we’ll continue to run a centralized server with good support (an unwalled garden, if you will) with the option to export your data and install a homebrew IDB Engine server if you prefer it.

The major downside to installing IDB Engine locally is that local installations will not benefit from the ever-growing community libraries on Indaba such as previously fielded survey questions and reuseable workflows. If we had a way to allow peering of data between IDB Engine instances, we would gladly share these, but that’s technically out of our reach in the short-term. Meanwhile, the good folks at CKAN.org are working on data peering, which we watch with interest; a decentralized but seamlessly interoperable data web is a vision we’ll work towards.

Where we are most optimistic about community contributions is in Indaba’s publishing widgets. These are small, modular visualizations of Indaba results data, and invite creative hacking. Frankly, I don’t expect a lot of volunteer coders to start tweaking the core Java applications — it’s big, it’s complex, the learning curve even to get it installed is going to be steep. The publishing widgets, on the other hand, seem like a good fit. It lives outside the Indaba data API, so a front end Web designer working with an Indaba partner could assemble new visualizations or reports that could be eagerly adopted or modified by later projects. Our widget source code is currently downloadable from Indaba Publisher, and we are delighted to have partners hack on them and submit new versions back to the community.

A bit about names: IDB Engine is the entire codebase running Indaba. We’re not calling the software itself Indaba, because we want to differentiate between the Indaba platform — inclusive of the hosting, the consulting, the 24/7 support, and, most importantly, the community of practice — and other instances of IDB Engine. Those installs may well be better and more successful than Indaba, and we wish them well. We think having different names will help users understand which one they’re getting.

Your feedback is welcome

We welcome your input on this and all things Indaba. Questions, suggestions, rude ASCII art? Bring it on. Please leave comments below, or contact us at info@getindaba.org.

– Jonathan Eyler-Werve

During the past year, Indaba has moved from a good idea to a field-tested tool with strong user validation. Of the organizations that have completed a project on Indaba (Global Integrity, Transparency International UK, Publish What You Fund), all of them are scaling up their use of Indaba with new projects. I can’t think of a better metric for success than that.

Here’s a review of the last year, with some insight into our learning process and findings. We’re not big on glossy sales pitches — this post includes some fairly brutal self-analysis of our strengths and weaknesses. Your feedback is always welcome at info@getindaba.org. Thanks as always for your support and interest.

In a personal note, after ten wonderful years, I’ll be retiring from service at Global Integrity in 2012 to take a sabbatical and pursue projects in Chicago. You can follow my next steps at eylerwerve.com.

I leave the Indaba project in the capable hands of Monika Shepard, Nathaniel Heller and others at Global Integrity and our growing network of partners and contributors. Working with the Indaba team has been the highlight of a great run — thank you!

Jonathan Eyler-Werve
Director of Technology and Innovation
Global Integrity

Our process

Our thinking is evolving fast as Global Integrity is settling into running a small tech startup within the larger organization. One lesson learned has been to resist grandiose feature expansion in order to focus on a lean, iterative, and user-oriented approach to upgrades. This has been a good year for this, as our Early Adopters program provided us with a structured dialogue process with which to constantly challenge our hypothesis about our market fit.

While most of our initial ambitions remain intact, our focus is much sharper. In particular, we are very clear on two things:

1) Scorecards (blending text and datasets) with a workflow are what people can’t get elsewhere. This is Indaba’s core value proposition.

2) Our project install process is too slow. This needs to be less complex for project managers (fewer decisions to make) and less work for admins (data entry chores shared with more users; lower risk of harm from misconfigured settings; faster launch, test, and adjust cycles).

How we learn from users

We took the following steps to gather user input:

• Field contributor surveys that captured three years of baseline experience from our previous-generation fieldwork tools and compared that to data from Indaba users.
• On-site trainings and Q/A with partner project managers in the Philippines, Mexico, Kenya, UK, US, and other locations.
• Several dozen webcast trainings and Q/A sessions with diverse populations of field contributors (for the record, American journalists are the most skeptical users).
• On site, multi-day project design sessions with partner organizations in Atlanta; London; Manila; New York; Port Morseby; and Washington, DC.
• A day long visioning session around future features with internal Global Integrity admins and project managers in one room, proposing and ranking options.
• Year-round capture of requested features into system documentation.
• Sharing an open plan office with Global Integrity project managers who are using Indaba every day.

What we learned (or confirmed) by talking to users

• People like Indaba’s scorecards. Creating a structured, indicator-based analysis with peer review and workflow attached is the function that no other tool can deliver to users.
• Project scale matters: Building a giant wooden deck? Get a nail gun. Hanging a picture? Get a hammer.  Google Forms is a hammer. Indaba is (metaphorically) a nuclear-powered auto-feeding large bore nail gun. It works best for large, repetitive projects.
• Managing text document workflow at medium to small scale (producing less than 30 docs) isn’t the most valuable use of Indaba. If it’s small enough to fit your files in one folder, you should consider running the project via email attachments, which is inherently more flexible at some costs to security, stability, and management complexity.
• There’s little current interest in using Indaba to purely manage file uploads (photos, video, audio, “blob storage”). However…
• There’s lots of interest in attaching files to a survey data point. For example: an Indaba researcher can now attach PDFs of legislation to individual scores in a policy scorecard, providing a reference doc that is more permanent than a government website which might go offline at any time. We’re not aware of other Web-based tools that do this, although tools such as DocumentCloud can be useful in more journalistic projects.

Raymond June uses Indaba from a Hawaian Internet cafe. (image: cc by/sa Raymond June)

Does it work? — Observations on user experience

• The “Fieldwork Manager” (runs fieldwork for remote teams and managers) emphasized usability and stability in our initial build. It has proved highly successful with end users.
• The “Designer” (used by Indaba admins to configure projects) emphasized lowest possible cost over usability in our initial build. It has proven difficult to use and needs serious help before we can scale up the number of project deployments. It’s slow and is a source of risk, as misconfigured projects can impact system stability. This is partially addressed in Indaba 2012.
• Trouble tickets from field staff are increasingly uncommon. We’re seeing 1 to 2 trouble reports a month from a user base of ~500 people active in any given month.  Roughly 3,000 assignments have been completed on the platform, with ~30 trouble tickets generated from those field contributors.
• Internet censorship is a problem we can work around. Yemen’s state-owned telecom classifies Indaba as pornography. Timor Leste’s telecom blocks access for reasons unknown. In most cases the free Hotspot Shield VPN circumvents the local blocking.
• More than half of our trouble tickets are resolved by updating field contributors to a supported web browser. We are becoming more comfortable requiring field contributors to update browsers, as the security considerations around 10-year-old browsers (Internet Explorer 6) make it a worthwhile battle to have with field contributors, regardless of Indaba’s needs.
• Project managers outside of the Global Integrity office (i.e. Global Integrity’s local partners and outside groups using Indaba) have offered consistently positive feedback. We actually would prefer a bit more pushback, but mostly they just tell us they “love it.” As an interesting control case, Global Integrity Executive Director Nathaniel Heller facilitated a feedback session in early-December 2012 between project managers at a large international NGO and their field contributors. The teams had recently completed a pilot research project by fielding 75 indicators across multiple government ministries in three countries. They used Survey Monkey to gather their pilot data, and the uniform feedback was, “We hated Survey Monkey.”
• Project managers are at times overwhelmed by the options available at project launch. We are working to create simplified options based on the choices made on previous projects (“Do you want chocolate or vanilla?” instead of “Configure these 31 flavors of variables…”).
• Global Integrity managers have reviewed ~50,000 scorecard data points on the platform with good results.  They have a number of usability and feature requests, which are reflected in the upcoming Indaba 2012 build.
• Global Integrity managers are less enthusiastic about using Indaba as a tool for the editing of text documents, as noted above. Recent workflows involved the submission of text from field contributors via Indaba, an offline “editing” process, and then inserting final text back into Indaba for peer review, approval and publishing. This reflects the reality that mature text editing/versioning tools are widely available (Microsoft Word and Google Docs are pretty good at this) and we are not willing to replicate this functionality in Indaba.
• Of the initial outside groups to complete projects on Indaba (Publish What You Fund & TI-UK) both are using Indaba for new projects within weeks of completing their original projects. Global Integrity continues to use Indaba for all data collection projects.
• The publishing tools are less rigorously tested than the rest of the system, because there is a 4- to 12-month lag time between starting and publishing a project. This will change over the next six months as the first wave of projects is published. Global Integrity has successfully published two projects through Indaba to the web (the Global Integrity Report: 2010 and the Kenya City Integrity Report) with no significant challenges.

What we learned from other people’s projects

In addition to our own users, we also have been in contact with others in our field that are developing tools in the same space.

On the input side: mobile device data collation is well understood by Nokia Data Gathering, Ushahidi, Citivox, and Frontline SMS. We’re in contact with these groups and could, if needed, build links to Frontline SMS or Nokia Data Gathering as the first step of a workflow that included both mobile input and Web based submission and review of data. We currently believe that we should not build custom mobile input tools for Indaba since it’s possible to link to very good existing tools.

On the output side, we’re talking to CKAN.org and the Open Knowledge Foundation about hosted data stores. Our users are frequently requesting a place to host/distribute/visualize the completed datasets they already have in hand. We’re undecided as to whether to support this use case (it’s not a big expansion from what we already have) or send them elsewhere so we can focus on managing field teams. Creating a bridge between the Indaba database and a CKAN-like network of databases is an attractive long-term goal depending on demand.

We learned about other projects while presenting at events organized by the World Wide Web Foundation, Aspiration, the Transparency and Accountability Initiative, and others.

Note to readers: if you run a project that we should be aware of, please contact us!

New features added since launch

While we have not emphasized expanding the feature set this year, we have incrementally updated what we have based on user feedback and our original road map.

• Automation of daily/weekly/monthly system backups.
• 24/7 monitoring and alarms for HTTP availability and application response (see Uptime section).
• Allowing file attachments that are embedded into scorecard in Fieldwork Manager. This functions similar to the “reference” text field.
• Support for “Not Applicable” score formats.
• A “Force Exit” feature which gives managers better options for handling an assignment that has been abandoned in progress by a field contributor.
• Research into how to improve the display of dynamic visualizations. (Best approach appears to use Flash on the server side and display cached image files to the Web. Flash has mature charting tools, but is not desirable for end users. HTML5 or jQuery are options, but we’re late adopters by nature.)
• Partner user branding integrated into Fieldwork Manager.
• Improved attachments support in text tools.

System reliability

Uptime for the first 14 months has exceeded our best hopes. Based on our monitors (which run once a minute):

• Our total unplanned downtime was less than ten minutes.
• Two network availability errors that resolved within five minutes each.
• Server/application stack has had no unplanned outages, though one planned server reboot was not communicated effectively, leading to approximately 4 hours of downtime.
• We had one incident of limited performance (scorecards were unavailable) for 6 hours total.  This was due to a database error in which a misconfigured “delete” button affected database records. The Indaba ops team recovered all functionality without data loss within 6 hours, despite the error happening at 5pm on a Friday.
• Hurricane Irene damaged hardware associated with the Indaba development environment but no data was lost and the storm did not affect system performance.

Staffing

We continue to work with and recommend Open Concept Systems as our engineering and operations contractors.

Monika (Kerdeman) Shepard joined the Indaba team within Global Integrity in August 2011. She is focused on staffing project design, support to users, and community building. Monika contributed to Indaba user stories while at the World Resources Institute and has been highly successful in bridging the gap between user desires and system realities.

Jonathan Eyler-Werve is transitioning out of Global Integrity at the end of 2011 to take a sabbatical and explore projects in his hometown of Chicago. He joined Global Integrity in 2002 and has been working remotely since 2005.

1) No lifeguard on duty: Each project manager will moderate her own community in terms of politeness and peer-to-peer interactions, according to whatever standards you find appropriate. We don’t provide any moderation or monitoring of your teams.

2) Don’t get us arrested: Don’t use the system to do or store anything that would be illegal in the United States.

3) Don’t try to break stuff: Don’t use the system in a way that degrades the experience of other people’s projects, or gives you access to information normally limited to other users.

This policy may change at any time. Feedback welcome.

The bottom line is this: if you work on human rights, anti-corruption or other politically sensitive topics, your email and online behavior is being intercepted and archived by security services worldwide. It is scary. It is unavoidable. It is also routine. People can and do operated effectively knowing that governments and corporations will read their email. Your behavior will adjust somewhat, but life goes on.

However, some basic precautions can push back against this by preventing less sophisticated attacks. For example, the recommendations below would likely have prevented the widespread interception of Facebook passwords by Tunisian security during the 2010 protests. All of the products below are free; most are open source and “libre” as well. They are also chosen because they run silently and do not require care and feeding. Annoying tools get uninstalled, so we’ve limited the list to things that run unobtrusively and have been extensively tested.

Firefox
Why: Online security starts with an up-to-date browser. We recommend the brand-new Firefox 4. I’ve been using the beta version for several months and it’s a great browser in many ways. It’s also more secure than any alternative on the market (both Chrome and Internet Explorer have their issues), so we require it of Global Integrity staff.
How: Download the browser, and set it as the default. Set the browser to never record your page history. If you have an older version of Internet Explorer, uninstall it entirely.
http://getfirefox.com

We also suggest you to run the following browser plugins, particularly on laptops.

HTTPS Everywhere
Why: Forces many popular sites (Facebook, Google, etc) to use encryption, preventing some spying.
How: Download plugin.
https://www.eff.org/https-everywhere

AdBlockPlus
Why: Prevents adbot trackers from loading, in addition to blocking ads.
How: Download plugin. Pick the default “subscription” for your language of choice — this is the ad blacklist.
http://adblockplus.org/en/

Ghostery
Why: Blocks tracking scripts and other badness.
How: Download plugin. Configure to “block all” and “no alerts” so it will run silently.
http://www.ghostery.com/download

Web of Trust
Why: Warns of known malware websites via a popup and reputation icons on search results pages.
How: Download plugin. Set security to less noisy “moderate” setting.
http://www.mywot.com/en/download

For wifi devices:

Hotspot Shield virtual private network (VPN)
Why: Prevents local snooping by creating an encrypted “tunnel” between your PC and a random IP address originating on US soil. Also defeats much local censorship, by obscuring the sites you are looking at. There are many VPN services; Hotspot Shield is a free, ad-supported service.
How: Install the Hotspot Shield client to your machine. You will then have to activate the VPN each time you want to use it (use it any time you are on wifi or an untrusted local ISP). You should do this before you open your browser. Hotspot Shield will slow down traffic, but should work ok for everything except video.
http://hotspotshield.com/

For portable storage (mainly laptops, but also portable hard drives and thumb drives):

TrueCrypt disc encryption
Why: Encrypts data on hard drives. Many jurisdictions, including the United States, assert the right to examine (read as “copy”) your hard drive at any border crossing, even without a cause for suspicion. Encryption also prevents harm from loss or theft of a device.
How: This takes a little work to set up, but there is good documentation on the TrueCrypt website, and once it’s installed, it is very stable and simple to use. I recommend full disc encryption for laptops; there’s too much system information that leaks out of an encrypted vault.
http://www.truecrypt.org/

If you run Windows, you should also be running Windows Security Essentials (a reasonably effective anti-virus / anti-spyware program from Microsoft). If you’re running AVG Antivirus, you can replace it with the Microsoft product; AVG has gotten intrusive and unstable lately so I have stopped recommending it. Running a Linux operating system (like Ubuntu Netbook) is almost always more secure, but is outside the scope of this guide.

If you are using a device that forces you into a browser other than the one you choose, you have a defective device (ahem, iPad). Perhaps you can return it?

I can also give a shout out to Skype, which isn’t a browser, but is a reasonably secure way to chat with people.

For more advice on this subject, consult the experts at the Electronic Frontier Foundation, such as their excellent Surveillance Self Defense guide.

Interview by Monika Kerdeman for Benevolent Media.

On February 16, former President Clinton and 200 social innovators, technologists, entrepreneurs and philanthropists gathered at Ford Foundation for the Wired for Change event to discuss how to create an innovative and equitable digital future.

A good overview, including archived “live blogging” posts, can be found on Jillian C. York’s website.

The following is a brief Q&A I conducted with one of the lucky attendees, Jonathan Eyler-Werve.  Jonathan is a journalist, designer and social entrepreneur, who works as Director of Technology and Innovation at Global Integrity. He’s currently working to make the Indaba fieldwork platform a beautiful tool for NGO fieldwork.

Monika Kerdeman: So, you were one of the lucky 200 people who attended the event. Can you explain your background and why this event is important to the work you aim to achieve at Global Integrity?

Jonathan Eyler-Werve: I’m the project lead for the Indaba fieldwork platform, which is an online tool that aims to make it easier for distributed organizations like an aid agency or an NGO to collect information and publish it. I sent Wired for Change an email and said, “Hey, you probably have some practitioners at this thing” and they agreed.

I’m a policy person by training, and I wanted to be in a role where we could grapple with big systemic questions. I ended up in public interest journalism. At my first job, my team needed a simple database set up, so I spent a couple hours reading the help files for Microsoft Access, and I put it together. This is a dangerous thing for a reporter to do, because these databases are really useful, and pretty soon I was doing more work on the backend stuff—figuring out how to tell stories—than I was reporting. Ten years later, here I am.

The Wired for Change event is essentially that conversation all over again, at a civilization-scale level. How does information drive good, progressive change, and what interventions can we take to enable or accelerate that? But intervention is a late-stage discussion, and this event was often more foundational. What does the present look like? Who wins and who loses? Are we OK with that arrangement?

MK: From your perspective, what are the critical barriers that have traditionally been overlooked?

JE: I am skeptical going into technology discussions because there’s such a disconnect between rhetoric and reality. It can seem like dueling straw man arguments where technology will save democracy or destroy it, which it totally might, but not for the reasons you get on CNN. So I was ready for anything.

As it turns out, I was really blown away with what the Ford Foundation chose to put on the agenda. They pointed at essential, under-the-radar issues: how to keep the Web open and interoperable; why U.S. broadband duopoly happened and what the consequences are; the crucial difference between regulating pipes and regulating content; the role of institutions (government and corporate) as gatekeepers to information and what we can do to fight that.

These are infrastructure for democracy, and it’s a problem that has been around for a long, long time. At the founding of the United States, there was a raging debate between pragmatists, who argued that the U.S. Postal Service should give newspapers deeply discounted mailing rates, and the idealists, who believed that the USPS should carry newspapers for free. Likewise, the founders insisted that mail service should go all the way to the frontiers, because you just can’t run a democracy without cheap, unrestricted and diverse sources of information. Same issues, new platforms.

MK: How do you think organizations, funders, social innovators and philanthropists can work together to overcome the silo barriers that exist in sharing technology, information and other things?

JE: I think that Luis Ubiñas, president of the Ford Foundation, is kicking the anthill here. He’s trying to start a conversation inside other foundations and within Ford itself. This was a culture change event. Luis is an interesting guy, hired from McKinsey & Company, where he helped media companies think about their new realities. Luis spoke near the end of the need to get technology out of the “overhead” silo and into the strategy conversation, which is essentially giving foundations the same question that newspapers are flailing with: the ‘net changes everything; how will you change?

This sounds like a really good conversation to have right now. And they’re starting with good people and the right questions. So I am on Team Luis. I am in.

Ford invited really good people too: Yochai Benkler, Tim Berners Lee, Gigi Sohn at Public Knowledge, the Global Voices folks, the Mozilla Drumbeat people. Giving them a timeslot next to Bill Clinton is probably more uncommon than people realize.

MK: Do you think the ideas discussed pertain to people around the globe or did they focus on solutions for the developed world, which operates in a different vacuum for tech needs and capacities?

JE: I think these questions are very broad and can be applied in a lot of places. There are winners and losers. There are people who are included in conversations about regulation, about restriction of expression, about terms of service, and there are people who are left out. These aren’t technology questions, which we see all the time at Global Integrity. The process is broken in really similar ways in both the rich and poor countries.

I was pleasantly surprised that we were able to have a conversation that shifted between Internet censorship by the Egyptian government and censorship on U.S. school and workplace networks without pausing. It’s the same questions of individual freedoms, institution controls and technologies that might tip the balance of power to one side or the other.

MK: As a member of the NGO and civil society community, as well as a social entrepreneur and technology innovator, is there any advice you would like to provide to funders to ensure the needs of the people on the ground are met?

JE: This needs to be a conversation. There is a movement out there of people who want to see technology serving and expanding democratic participation, improving social services, bringing justice. It doesn’t have a name, but it does have email lists (e-democracy.org, for instance) and meetings (usually with “Camp” at the end of the name) and people the movement respects and takes guidance from, like Tim O’Reilly.

The first thing funders should recognize is that these people don’t want or need money. The second is that this movement can be really useful in getting money allocated to the right projects. This is going to be opportunistic. This is going to involve taking risks on things that are half-baked. It will involve trusting really smart people to respond to emerging opportunities. A funder who can live in that world, go to the meetings, contribute on the message boards, without doing harm to it, would be a powerful ally.

MK: From the info presented, what shocked you the most?

JE: Well, having John Hodgeman dropping a reference to “Rube Goldberg porn videos” was unexpected. There was a spirit of humor and whimsy to this event that I really enjoyed. If this stuff is boring, you’re doing it wrong.

Editor: Thanks to Monika for suggesting Jonathan attend this event in the first place, and then for writing this piece.

The Indaba fieldwork platform helps organizations collect data and reporting and publish it. This document describes the need for Indaba, our thought process when building it, and what it does. See related documents here:

• The Feature List (a short version of this paper)
• Indaba Adoption Scenarios
• Video demo and discussion

Indaba enables groups of people to design projects, collect data, write reports, edit documents, clean datasets, conduct quality control and peer review, and then publish or export the results, all from a web browser. Indaba’s workflow manager allows geographically distributed teams to collaborate online with minimal oversight, allowing projects to scale up.Indaba also has tools to manage relationships, control access to common content, and promote accountability for a group of contributors working on a data gathering or publishing project.

Designed by a coalition of non-governmental organizations (NGOs) convened by Global Integrity, Indaba aims to dramatically lower the time and cost of measuring and tracking fuzzy social issues (transparency, service delivery, human rights, etc.), while promoting and sharing best practices and methodologies across the social sector. By using a common, open platform, data from across the social sector can be compared and reused, encouraging the use of best practices and open, interoperable data formats. Indaba is a Web-based software-as-service requiring no local installation with field staff or home office.

Why We Built Indaba: A Brief History of NGO Data Gathering

At the turn of the century, voices within the aid donor community were calling for more systematic approaches to aid, particularly around issues of corruption and governance. Aid, it was argued, should be concentrated in countries with good performance on anti-corruption. Corruption rankings such as the World Bank’s Worldwide Governance Indicators or Corruption Perceptions Index were suggested as triggers for aid flows.

This was a good idea, but with a serious flaw: the metrics being used to rank countries on issues crucial to development were, in the view of the field’s best thinkers, entirely inappropriate for this use. [1, 2, 3]

Governance indices typically took three forms: mashups of third-party survey data, statistical analysis of newswire headlines, or a handful of hyper-educated Westerners ranking every country in the world based on things they had read or heard from friends on the ground. These rankings were frequently of limited value for suggesting specific policy reforms and tended to track very closely to the consensus views of Western elites.

The development sector desperately needed better data, especially data reflecting local realities. Several organizations waded into this tiny crisis with a better vision: break complex issues (“corruption”) into hundreds of discrete, measurable concepts (“Are jobs in ministry XYZ given out through a competitive process?”). These assessments focused only on things we could actually change. Rather than use a single number to assess an entire country, these second-generation datasets produced actionable, disaggregated insights, often with narrative explanations for why a score was given.

Answering these questions required better primary sources, which led to the creation of the distributed NGO, a new media model where a loose network of reporters, activists, or researchers feeds information to a central organizer. These organizations represented a radical shift away from Washington/London/New York/Brussels as monolithic voices in development data and towards the simple but powerful idea that people living in developing countries have crucial insights into what is and isn’t working in development.

The challenge in executing this new approach was that collaborating with hundreds of people in dozens of countries is a lot harder than the old five-people-in-one-room-in-New-York approach. None of the groups working on these issues had a budget to open dozens of field offices or fly everyone to one place. Using the Internet was the only way it could ever work. Indaba is the latest iteration in eight years of technology development at Global Integrity aimed at building tools to make distributed NGOs work over the Internet.

Why Existing Technology Wasn’t Good Enough

In the summer of 2010, the Indaba team went on a listening tour with projects at seven distributed NGOs. What we found was troubling. The majority of institutions we talked to use Microsoft Word documents or Adobe PDFs as their primary database for quantitative datasets. Typically, data are collected in Word documents or PDFs, then emailed back and forth during quality control processes. Finally data are transferred, usually by hand, to an Excel spreadsheet as the final data repository. In one case, an organization emailed Word files to and from the home office until the files became so huge that the files inevitably became corrupted in transit. They would then print the documents onto paper and retype the data into a spreadsheet by hand. The project managers did this for more than 10,000 data points.

Suffice it to say that there are a number of disadvantages to this approach. The more interesting question is why smart people at these organizations continued using Word and PDF documents as their solution.

One answer is that there aren’t a lot of tools off the shelf that address the issue of managing workflows in organizations, and fewer that integrate content and relationship tools. Content management systems (like the very good Drupal CMS) are good at storing and publishing content, but don’t reflect the internal workflow of organizations. Project management systems, on the other hand, typically are not good content databases.

A second answer can be found by focusing on the end users, examining the constraints facing staff in distributed NGOs and what software would be realistic in improving their situation. These are hyper-connected people with multiple jobs, working from Internet cafes and university computer centers. Pushing new tools on these overworked people is not a good use of project managers’ limited influence, so organizations use the ubiquitous tool of our time — Microsoft Word — and do whatever it takes back at the home office to make it work. This is, in fact, good user-focused design.

But it’s awfully hard on those project managers. A sad consequence of this is that NGO data tends to be published in difficult-to-use formats, without metadata, common IDs with other datasets, or even good internal structure. NGOs avoid a highly effective methodological approach of matching quantitative data with deep narrative description (getting beyond “what” and to the “why”) simply because the technology to manage these datasets is unavailable to them. Much of this is compounded by fatigue, as exhausted project managers simply want to get something out the door before time or money runs out.

In some cases, organizations focused on beautiful printed materials treat online access as an afterthought. In one particularly strange technology decision, an NGO aimed to replicate the print experience so completely online that the high bandwidth website played the sound of a crisp paper page turning to online visitors. It did not, however, allow readers to copy and paste text.

Consistently applying best practices for publishing would be an improvement. But there’s potential for much more. In the late 1990s, blogging software radically transformed individual publishing by making a simple thing — putting text and images onto a website — much easier. In the decade since, an explosion of new, unexpected expression has occurred for individual authors. Today, organizations that publish data and reporting are in that “pre-blog” state, where doing simple things, like emailing a Word document, processing it for quality control and publishing it to the Web, print, or datasets are simple but tedious, difficult to automate, and stressful.

If we can take that stress away, the potential growth of new data gathering and publishing is huge. If we lower the costs of publishing for distributed NGOs the same way that blogs did, we can transform not only established organizations but also empower start-up, grassroots, and unexpected sources of structured analysis and data to inform public debate. That is our ultimate goal with Indaba: the democratization of voice and official knowledge to include every group of people with something to say.

Indaba: What It Does

The Indaba fieldwork platform is a collection of tools that organizations can use to run projects that collect and publish text, data, or any kind of file (such as images or video). It is well suited to large teams of contributors working remotely on projects which collect structured information such as scorecards, comparative analysis, or other publishing efforts where content is created in discrete chunks and repeated at large scale.

Indaba is highly flexible, allowing each project to define workflows, user roles, content types, and other key variables to match the preferred working style of that project. Once created, these project definitions become useful starting places for future projects, encouraging incremental improvement and the transmission of best practices across the social sector. When a project is complete, the data is stored in a well-structured database ready to send content to web, print, social media platforms, mobile devices, or file exports. Indaba consists of a large database with several software applications that move information in and out of that database.

There are currently three core applications involved in an Indaba project: Designer, Builder and Publisher. Additional input or output applications can be added as technology matures, such as mobile device or tablet input.

Designer

Designer is a web interface used by project managers to define a new project. For new organizations, this is a consultative process of making a project design explicit and repeatable.

Most of this effort happens offline with a pencil and paper, guided by a representative from the Indaba team. The most important aspect of this is the creation of a workflow for each type of content to be published. The workflow defines each goal that must be completed before a document can be published. Even on paper, making a workflow visible tends to improve how projects run. With Indaba, the workflow becomes a foundation upon which to build your project. At all steps, existing Indaba projects can serve as a template to modify from or adopt entirely. Once created, your project definition becomes a valuable starting place for future projects at your organization and others. A project definition involves deciding the following:

• what products you want to publish,
• what format (text, questions, files) those products will take,
• what kind of roles your staff will have,
• privacy and peer-to-peer visibility rules for each role,
• permissions and access to features for each role,
• setting a workflow for each product,
• creating rules for each workflow assignment such as deadlines or completion requirements,
• how will users will be given assignments (in advance, self-claimed from a queue, or assigned on the fly), and
• creating automated and custom notifications, such as deadline reminders or thank you notes.

Designer’s workflow manager is one of the few unique aspects of the platform. Workflows are defined with a high degree of flexibility, meaning that workflows can branch, circle and recombine in whatever way the organization requires. An example workflow might look like this:

• Field staff signs contact
• Field staff submits data
• Office staff reviews data and discusses revisions with field staff
• Editors, libel reviewers and fact checkers each claim this document out of a pending work queue, and engage with the content simultaneously.
• Peer reviewers gain access to the document after all three of the previous staff have completed their work. Peer review lasts until a deadline, or until 80% of peer reviewers have completed a review.
• Office staff reviews peer review feedback and discusses results with field staff.
• A manager makes a final review of the document before approving it for publication.

Each step in the workflow has unique rules that control deadlines, notifications, and other options that are configured in the Designer application. Designer is a hosted service using the following technology stack: PHP, Tomcat, MySQL, Linux, Amazon cloud hosting.

Builder

Builder is a core web interface used by all contributors to a project, including authors, editors, managers and reviewers. Builder is the centerpiece of the Indaba platform, the tool used to automate and manage the workflows defined in the Designer tool. For most users Builder is the only part of Indaba they will see.

In Builder, users can do several things…

Complete assignments.

The concept of assignments is the core of Builder. Each workflow goal (defined in Designer) is broken into one or more specific assignments that go to individual users, who are then accountable for finishing them. When any user logs in, they are presented a list of their pending assignments. From that list, each assignment links to a specific piece of content, viewed with a specific tool. Each tool is a unique interface devoted to doing a specific kind of work, such as editing a text document, or reviewing and commenting on a dataset or scorecard. Existing tools allow for several forms of text editing, data input and cleaning, comment and peer review, or simply logging that an offline event (such as hiring or paying a researcher) has occurred. New tools can be created with relatively simple Web development, making the system extensible to new kinds of work.

Monitor work in progress.

There are a number of ways to see into the progress of work in flight. Depending on a user’s permissions, this can range from only seeing the relative progress of that document compared to others generating the same content, up to detailed status reports and the ability to export or edit the document. In particular, Indaba focuses on two key metrics: identifying areas where work has stalled, and making projections about when workflows will finish.

Use the case manager to fix problems.

Automated workflows are great until something unexpected happens. When it does, humans need to get involved, collect information and make decisions. Indaba has an integrated case manager for addressing fieldwork problems on or off the system. The case manager serves as a unified place to collect information on a problem, share that with relevant users (users and content can be “attached” to a case), and rank the severity of the problem. The case manager is integrated with the document workflow: if needed, the case manager can either freeze progress of a document or prevent a document from publishing until the problem is resolved.

Manage assignments via queues.

As goals are completed, documents will pile up waiting for review or editing. Indaba uses queues to allocate these assignments when a group of people are sharing responsibility. This allows for very efficient allocation of assignments to people with capacity to complete the work, and allows people to self-assign into assignments of personal interest. Queues can also be owned by a manager who assigns the work as it comes in. Once a user claims an assignment, they are accountable for finishing it, but if needed a manager can shift assignments in progress to new people.

Send messages to individuals, or groups.

Builder has a built in sitemail messaging system that works like a very light version of a webmail system. This exists to solve two problems. One, sitemail enables an email-like communication with people working anonymously or in areas where email censorship is a barrier to reliable communication. A more common application is to quickly find and send messages to your field staff. Indaba’s sitemail has your entire team loaded into the “to” box. For users with appropriate permissions, Indaba also enables messages to preset teams (arbitrary groups of users), to specific roles (for example, all field researchers), or to the entire project. This is also possible over email, but in practice, we believe having a place for instant lookup of up-to-date field staff contact information leads to better communication between the field team and managers. Sitemail is forwarded to users’ real-life email inboxes by default. Builder is a hosted service optimized for reliability and stability under heavy load. Builder uses the following technology stack: Java, Tomcat, MySQL, Linux, Amazon cloud hosting. Builder is actually two independent Java applications, one to serve pages, and another to manage background events like email alerts.

Publisher

Publisher is a web interface that allows project managers to export and publish content stored on the Indaba platform. As with all Indaba tools, this is permission controlled; users can access only eligible content. Publishing takes three forms:

• Bulk export: text, datasets, and files can be exported in a variety of file formats including the most common, as well as open standards. With a bulk export, content can be transferred to the content manager of your choice.
• Widgets: widgets allow organizations to quickly and easily serve content created in Indaba over the Web, similar to embedding a YouTube video. Indaba widgets are open source (using an Affero GPL license), and we encourage customization and sharing across our community. Have you finished compiling a bunch of scorecards and want to quickly publish them on the web? Indaba’s scorecard widget can get your content online, with professional polish and navigation, in minutes.
• API interface: for greater control over information served via Publisher, an API allows custom built applications to display content with a high degree of flexibility and customization.

The Indaba Design Concept

The previous section explained what Indaba does. Now we turn to explaining why Indaba is designed the way it is. Let’s go back to our project managers using Microsoft Word-over-email. The decision to use Word is very important: a technical solution must reflect the working style of all participants, and these people clearly prefer using simple solutions and ubiquitous tools over more complicated approaches. This has guided our thoughts towards the following design goals.

Integrate project management, content management, and relationship management.

Indaba is not a universal solution that will manage all of your organization’s projects, manage all of your content, or store all of your contact information. But in the context of a group of people working together on a large publishing project, it does each of those in a clean, quick, integrated way.

Access from any Internet link.

Users should be able to perform all system functions from the computer they already use, regardless of its condition, and without installing software or plugins. Many of our users work from Internet cafes or university computer labs. Using our entirely browser-based approach, users can write, edit, or manage data from any Internet-connected machine on the planet. In Global Integrity’s eight years of fieldwork in more than 100 countries, we’ve never had a contributor that didn’t already value their Internet connection. They already do whatever it takes to stay online, a process that requires no additional encouragement from central managers.

Today, all Indaba functions can be accessed from any computer with access to the Internet and either Internet Explorer (version 7 or better) or the Firefox browser. Indaba can also be used in smartphone Web browsers (iPhone, Android). Additional browser compatibility, as well as more purpose-built mobile integration, will be added over time, driven by dialogue with our user community. Based on community feedback so far, we are exploring offline data entry via a desktop application. We are also looking at ways to enable paper-based data collection (perhaps via bar coded forms printed from Indaba and returned to the Indaba database via a smartphone camera) in challenging, remote circumstances.

A personalized, workflow-aware experience.

While technology can be a barrier to adoption, a more powerful barrier is the difficulty of training remote, part-time users. Our solution is to mimic the existing working style of our community: present field staff with a very simple, highly structured experience. Indaba’s workflow manager allows each user to see exactly what that person needs to be working on, and can limit visibility into non-essential content and features. As workflows progress, access to documents shifts in response. Peer-to-peer visibility can be limited to working groups of manageable size (i.e. a country team, or a technical specialty), or turned off entirely, as configured by project managers. Privacy can be configured on a user-to-user basis, allowing double-blind peer reviews, for example. Instructions and help are provided on-screen throughout the system, customized to the specific assignment the user is working on. Instructions are unique to each project and can be improved on the fly as field staff run into problems.

Managers can quickly see problems, sort by importance and solve them.

While we want to limit the visibility of field staff to their task at hand, the opposite is true of managers. These people need real-time visibility into every aspect of the project, distilled into useful dashboards and status icons. This goes beyond access to in-progress content to indicators of what’s happening inside of each workflow, with escalating alerts that notify managers of potential problems. Deadline awareness is built into every assignment. Email alerts can be fired to remind staff of an approaching or missed deadline, escalate to emailing managers, or start a new ticket in the case manager; these rules and messages are configurable for each assignment. As a result, managers can avoid having to constantly check field staff deadlines until someone actually misses them. User statistics provide useful insights into field staff engagement. For example, if a manager is investigating an overdue assignment, Indaba can indicate if someone hasn’t logged in for weeks (big problem), or if the field staff is regularly completing other work, but hasn’t gotten to that assignment yet (smaller problem). This keeps managers focused on solving the truly critical issues. Indaba allows managers to shift their perspective from a narrow view (a list of assignments they must complete) to a universal view (real-time status of every assignment, document, or case) as they like.

Grassroots and security ready.

Using an entirely web-based publishing platform has two important advantages. First is convenience. The total technical know-how needed for an organization to use Indaba is… none. There’s nothing to install at the home office, no databases to back up, no hosting to buy. An organization using Indaba doesn’t need a website at all, and in the case of start-up projects, they probably won’t have one until information is ready to publish. While this is merely convenient to traditional institutions, this may be essential to grassroots groups or non-traditional projects that lack dedicated technology staff.

Second, hosting everything in an online database limits risk for field staff in difficult security environments. A reporter can walk into an Internet cafe, contribute to a project and walk out again, carrying nothing incriminating with them. There’s nothing on a laptop to confiscate, and it is difficult to connect a visit to indabaplatform.com to a specific project. Indaba stores very little user data that are not voluntarily submitted (for instance, we do not log IP addresses), allowing anonymous contributors to work in relative safety.

Current status of Indaba

Please see our running status reports for up to date information on progress and availability. Your feedback is warmly welcomed below. Or join our email list here.

As transparency people, we’re happy to share the results with our readers.  In the month of January we were offline for 9 minutes and 50 seconds, due to two network failures between our monitor and the platform. That’s not a perfect record, but it’s pretty good. On the software side, we hit 100% uptime for the server running the Indaba sites. Full data below.

—

indabaplatform.com HTTP Availability Report: Jan/01/2011 – Jan/31/2011

—

indabaplatform.com HOST Availability Report: Jan/01/2011 – Jan/31/2011

—

Critical Events:

Indaba is designed to be stable and scalable under load. It uses a system architecture that is more robust than many commercial Web applications.

Indaba is hosted on a Linux server, running two Java applications (one serving pages, another handling background events) over a MySQL database, with Tomcat and Apache for the web server. Hosting is provided by Amazon Web Services (AWS), on a Large EC2 server instance. Hardware and network access are handled by AWS.

Backup and system recovery

Backups include the Indaba application code and all user databases, allowing a fast rebuild on a new server in the event of total failure of the Amazon hosting environment. Backups are daily and automated, stored within the EC2 server instance. Weekly and Monthly system backups are also automated. Data is stored on EC2 instance and also moved to physically separate Amazon S3 storage hardware.

• Daily backups are stored at EC2 for seven days.
• Weekly backups are stored at EC2 for 50 weeks, and on S3.
• Monthly backups are kept for 30 months at the EC2 server, and permanently at the S3 site.
• At completion of a project, a duplicate system backup is shipped to Global Integrity offices, encrypted and stored permanently.
• Project data such as scorecard results or narrative can be exported in a common file format at any point in a project.

Uptime and Monitoring

Indaba has a 24/7 event response service operated by its development team. Automated monitoring services check the system health and alert staff if unusual conditions exist. The following tests run continuously at five minute intervals:

• Host availability via IPCM ping.
• HTTP availability.
• MySQL database availability.
• SSH daemon availability.
• Tomcat memory usage for both public and workflow instance.
• HTTPD errors in log file.
• Tomcat errors in log file for both public and workflow instance.
• Disk space usage.
• Current system load.
• Current active users on host.

If an error is found or a threshold is reached, the monitor will retry 4 times. If all 4 retries fail, an alert will be sent to Indaba operations’ on-call service for investigation.

Hosting

Amazon Web Services is currently the world’s largest Web services company, serving more than 300,000 sites. They are contracted to provide service with 99.99% annual system up time.

• Amazon Elastic Cloud Computing (EC2 Northern Virginia) — hosts Indaba’s operating system and live project data.
• Amazon Simple Storage Service (S3 Northern Virginia) — hosts Indaba backup files.
• Realtime host status: http://status.aws.amazon.com