This blog was originally posted on the getindaba.org website.
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 atGlobal 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:
- Better automation for inviting project contributors onto the platform.
- Allow project managers to add and modify their “indicators” (survey questions) on Indaba.
- Allow project managers to add “targets” (the unit of analysis for a project; think countries, cities, clinics, etc) directly to Indaba.
- 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:
- 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.
- Better visibility into workflows — what exactly do those status boxes mean under My Content? More information would help, and we can do that.
- 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:
- Full-time HTTPS for all users.
- Encryption for all Indaba databases.
- Better browser compatibility to bring Chrome and Safari up to the same level of functionality as our “official” supported browsers, Firefox and Internet Explorer.
- 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.
- 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
– Photo by Global Integrity
