Adam in blog on March 30, 2011
Working with informality often means working in developing communities. Developing communities right now have a particular, varying, and evolving set of new technologies at hand. Staying up to date on what technology has reached where, and how it is being used, allows you to design a project that will suit the needs of the environment. Though we don’t exclusively deal with ICT (Information communication technology, particularly ICT4D, 4 development) this field is producing ongoing case studies and questions which are at the intersection of technology and informality.
In some countries in Africa mobile phones are beginning to reach everywhere, and in others these phones already have data and native apps. In any case, there are a range of tools that can be used to engage the existing technological frontiers that are in place, even if this is limited to SMS driven projects, radio programming, or traditional media. Applications and services are being designed to mesh with this frontier.
Within this production, lots of tools are built to solve a very specific problem. Certain groups are building very specific, and very formalized, technological tools and processes to address an isolated problem that they have identified. This approach is leaving a legacy of highly specialized tools for problems which are at times extremely unique or imprecisely defined. These tools are in general formalizations of specific problems and specific technologies. For example, a tool which is built to send and manage SMS messages to inform farmers of the daily crop prices, is a tool which has made a very formal procedure and infrastructure for using technology and spreading economic information. Essentially, formalization has created a rigidity within both the technology and information — of what could otherwise have been more dynamic and adaptable sets.
It is here that a toolbox comes into play. Tools are usually developed to address a discrete challenge. For example, a custom built tool to manage farmers phone numbers and crop prices, along with distributing SMS messages. Such tools have been an amazing first step in ICT4D, but an infrastructure of integrated tools can get this type of project running in a more adaptable way. A component in charge of each process, can allow the system to be recycled for different situations when necessary.
A number of technologies are already in place that believe in this toolbox approach. FrontlineSMS is excellent for simple off-grid SMS projects of all kinds–as the software is designed to manage messages of all kinds, with as little formalization of the projects as possible. Likewise it is open to a range of plug-ins and edits that allow integration witha range of programs. RapidSMS is a similar framework designed for larger scale applications with different project constraints. In another realm, DataDyne’s EpiSurveyor allows any sort of survey to be created and distributed via SMS, even though the initial intention was to collect health information. In fact it is this open ended approach that even makes a toolbox possible. DataDyne rather than contribute to a lengthy list of mHealth survey tools –one for malaria prevention, one for TB medication tracking, another for AIDS data, just built one survey tool that can be used for health and anything else.
These adaptable tools are moving, and should be encouraged, to be as compatibles possible. We have seen miracles assembled in minutes by integrating FrontlineSMS (an SMS application) with Ushahidi (a crowdsourcing mapping application). Furthermore, these tools should be as informal as possible. And what do we mean by this? More informal tools are more flexible tools. They don’t assume what they will be used for and they don’t formalize the process along the way. This leads to tools which have the most uses, the most impact, and the most integration.
Understanding the current toolkit, and where the holes are is essential to building development oriented technology for informality, particularly ICT4D. Beyond this though, understanding the nature and opportunity of such a toolbox also requires identifying the scalable functions within a project that can be used in other contexts. For a new project design, first dig into the toolbox and see whats there and what needs to be tweaked. Then find the holes in the project, and understand which of these holes might pertain to other problems and projects. This approach designs good, technologically agnostic projects, and develops informal plug-and-play tools. Stay tuned for more examples of these tools, these projects, and some upcoming work on the layout of this toolbox itself.