MobileActive.org

There is a fascinating discussion about the fuure of mobile apps going on over at Change.org.  Nathanial Whittemore started it all with a hopeful and visionary blog post on how mobiles will be changing the world.  The discussion thread turned into a thoughtful discussion on mobile appplications and how this emerging eco-system of tools scales and interoperates to maximize resources.

Isaac Holeman, working on (and twittering about) MobilizeMRS, points out that "interoperability is a very important point..where it's not necessary for any one installation of anything to scale completely because data can move into or out of any system.  Mobile health stuff is so new that interoperability of medical data has hardly been considered, to my knowledge. With MobilizeMRS, one of the primary reasons we want to interface with medical records systems is that a huge amount of work has already been done to promote medical record interoperability with standards such as HL7."

Steve Song from the Shuttleworth Foundation picks up the theme by noting,

"For me, this amazing initiative highlights how important it is for phones to become more tinkerable, by which I mean having more generic interfaces and operating systems that will open up innovation.  We don't think it is remarkable that PCs all have the same power cord or that all PCs and laptops have USB ports.  Yet USB ports have enabled a host of innovations on laptops and PCs alike.  Android is a good start as an Open OS for phones (although it still feels like bloatware for your average developing country phone).  Although I don't agree with Jonathan Zittrain's general thesis that the Internet is closing down, I think his argument applies very well to the mobile phone environment. Roll on OpenMoko!  Oh, and maybe go easy on the applause for Nokia et al.  Mobile manufacturers are very innovative but also clearly collude with mobile operators in their rent-seeking behaviour in developing countries.  How about a little openness, Nokia?"

Ed Jeziersky from Instedd tops it all with his overview of apps -- entitled so appropriately Phones don't change the world, people do. (Which reminds me of the Toronto manifesto that started the MobileActive.org network in 2005--Without the People, Technology Is Nothing"). He writes (and it's worth posting at length here, and emphasis mine!)

Nate’s post takes on a ‘remember the future’ approach where he fast-forwards to 2011, and paints a scenario where mobile technologies are widely deployed and used. I really like that approach to visualizing possibility, and wished it was used more as a social activity. Strong Angel and Superstruct do this too, in a way. ,

Question: When you plug something in do you say “I’m using electricity” or “I’m using the wall socket”? Sometimes I feel the discussion about innovation in mobile tech sounds like a discussion of innovation in energy…where the discussion centers on the design of plugs & sockets. A phone is just a conduit to a network, and a powerful, sensor-rich, user-friendly device can be underused as a collaboration tool that help people work better together if network reliability and costs are not managed in unison.

In my 2011, I hope that there are hybrid social-enterprise efforts that can make inroads to working with wireless providers and carriers. They need to evolve their offerings and provide the types of cost structures needed for health and social good to scale and not depend on infusion of donations to keep running OR pushing costs where they can’t be paid while willing customers cant spend their money. Even just helping providers make money differently would help a lot. Examples: toll-free-SMS?  Free-to-send? Free-to-receive? Mobile banking? Shared-costs billing? Provider-supplied location tracking of registered gov’t health staff? Anonimized tracking of random individuals for disease migration modeling? it goes on.. Providers could make more money (gasp!) and they don’t.

Beyond 2011 I hope more effort gets put into creating connectivity approaches that would be disruptive to current wireless systems. And I mean the “system” of government spectrum licensing + carriers + wireless providers + device manufacturers. But who would fund this research? Sigh…we need smaller, personal, cheaper GSM ‘towers’ that can be linked up more than phones. What would happen if every smartphone could host a 802.13 ‘peer’ network?

Centralized or Distributed mobile apps? There are no ‘best’ practices…There are only proven practices, in context.

When evaluating whether an approach fits a new situation, you have to consider the context in which other solutions succeeded or failed. I face this all the time in the discussion of ‘centralized’ versus ‘individual’ mobile solutions. Sometimes I get asked which approach is better and the answer is a) it depends b) you want both, not either/or.

 The centralized approach uses national or international-scale gateways, like Ushahidi with Clickatell, RapidSMS, InSTEDD GeoChat with Clickatell and BT, and so on. These are appropriate for national-scale programs, where reliability, performance security and availability of certain types are provided.

 FrontlineSMS is the archetypical individual or grassroots approach, where a phone attached to a computer acts as a gateway where you control costs, numbers, location, etc. – providing different types of reliability, performance, security and availability for different contexts. This type of ‘individual’ solution can even run in a smartphone, and FrontlineSMS and other projects are already proposing such a migration. For GeoChat, we put it on the backlog until we saw more demand for this approach from our Asia programs. Approaches like RapidSMS which rely on an Asterisk server can also work on a laptop, or on a server, and can help span a ‘middle ground’ between other solutions....

Some applications support both centralized and decentralized models (like GeoChat) but as we start working together in this budding mobile community it makes sense to pool efforts and re-use each others’ technologies...The goal is to be able to pick the right tool for the context, and all the applications mentioned above are already working on protocols that would let you have a hybrid deployment that would allow you to scale up or out as needed. As contexts change, having freedom to evolve your app and not be locked into one or another is key.

Once you are moving messages around, how do you make sure different applications interpret the information in similar ways?

Shared formats for data exchange

To achieve interoperability, and reuse the human capital of having trained users, mobile apps should also share conventions on what gets put IN the messages. There is a huge gap in defining what gets put on SMS messages for diverse uses:

• Free text, with specified language
• Free text with explicit tags
• Locations (lat/long, place names, village PCodes etc)
• Delimited data (e.g. Ed, Jezierski, Cambodia)
• Self Describing Data (e.g. firstn:Ed|lastn=Jez|city=Seattle
• Multi-Message batching, sequenced or order-agnostic
• Message batch retries
• Compression
• and the list goes on…

The community of builders of mobile apps for social purposes has to start catching up in this space. I suggest re-using the leadership of twitter and other services in evolving some conventions (eg @user, #tag) in common ways where applicable. I would also like e.g. Nokia’s data gathering solutions and other industry players e.g. Google to participate in the open forum, too.

For example, In the Cambodian Avian Influenza hotline pilot we implement batching and self-describing data over SMS. We should get together with RapidSMS, and define a common approach. This would let the Cambodian government switch out InSTEDDs backend and put RapidSMS transparently, if they chose to do so.

One example of this is GeoChat + JavaROSA. We want to support JavaROSA front ends to send structured data to GeoChat, and if we documented the format well, other clients (like Nokia’s?) or servers could be used interchangeably.

JavaROSA is an excellent open source project, great technology and well run. We have contributed the ability to do 2-way sync between phones and between a phone and a server, already.

Even with these agreements interoperability can also lead to a shallow openness, where applications work with others… as long as they can continue to hoard the data and lock-in users. You can see this happening over the last year in the space of social networking technologies, where many announcements of open approaches veil an underlying strategy of trying to become the ‘hub’ or the ‘one stop shop’. (emphasis mine)

Do the benefited populations really gain much if folks can collect more data, but we/they can’t move it around?

Sharing Data

We all know the limits to sharing data are political or incentive-based, more than technical. But technology makes a fine excuse for not sharing information. In the field one faces many silos – NGOs with different mandates, Government agencies with different domains (animal health, human health), research programs funded by different ivy league universities, not to mention ethnic, language and country borders.

The goal: An Open & Sustainable Platform for the end users:

We can’t forget that all these technology efforts are trying to empower individuals and organizations, and simplify the work of caring for one’s own community or for others.

All the technologies mentioned here are converging towards a shared architecture-–a platform for data exchange and collaboration built around mobile users in the harshest environments. A platform that can start small and grow transparently, or start large and continue running even if the centralized networks are unavailable. Because of this shared architecture, the end portfolio will be stronger, dollars spent on technology will go further, and users will have a simpler entry point to learn what are the right tools for their context.

Ed's entire post is excellent - read it.

One of the things that is missing from this discussion, however, is the notion Ken Banks alludes to when he says "An outsider reading elements of this discussion would likely see a bunch of white people arguing over what the best mobile health solution is for 'poor people'. Any technology which is brought in from the outside and forced onto a community of users is destined to fail." 

All of the applications and projects that are under discussion here -- without fail -- fall somewhere in the category of  what Richard Heeks calls "pro-poor" to somewhere on the continuum to "para poor."  This is a key notion and while Ken is right in noting this, neither his nor any of the other projects address it. 

Heeks describes the key issues in ICT4D (ICT for development) 1.0 -- key issues we have not moved beyond at all:

• Sustainability: The failure of many ICT4D projects to deliver and survive...;
• Scaleability: The limited reach of invidiual...projects;
• Evaluation: ICT4D 1.0 was often held aloft by hype and uncorroborated stories, which fostered a new interest in impact evaluation.  (emphasis mine)

We clearly have not moved beyons these three critical issues as evidenced by the limited sustainibility, scale, and hype that so many of the apps here discussed demonstrate. In short, ICT4D and M4D 2.0 are elusive. 

Heeks then notes what may be the most valuable characterization of these innovations -- the distinction between pro-poor, para-poor, and per-poor.  Pro-poor innovation occurs

"outside poor communities but on their behalf.. this can be an effective approach for engaging resources from the global North in devloping-country problems. However, it runs into the danger of design versus reality gaps: A mismatch between the assumptions and requirements built into the design and on-the-ground realities of poor communities." 

Para-poor efforts, in turn, Heeks says, are

"done by working alongside poor communities. The need for participative, user-engaged design processes was a key learning point [of ICT4D 1.0].  It's a lesson the informatics discipline generally learned several decades ago, but there is always a need to reinvent such wheels when new application areas arise, filled, as they are by a gold rush of new actors..."

He notes that commnunity participation is hard -- who participates matters.  I would argue that none of the projects we are discussing -- Frontline, RapidSMS, Ushahidi, Instedd's projects -- have fully embraced participatory design and taken into consideration who participates -- techies versus non-techies, rich versus poor, Western versus non-Western mindset, urban versus rural, and men versus women.  I am glad to stand corrected on this point, but none of these projects have demonstrated that they really understand what is means to design in the context and with the communities they serve.

Lastly, Heeks notes per-poor efforts -- innovations that occur within and by poor communities.  These include new processes -- think beeping, for example, new business models, new products.  There has been very little discussion, save on the part of observant researchers, to think about mobiles for development from a para, or even per-poor perspective.  In that context, an enabling environment in developing countries  -- availability, , skills, uptake, impact, and a ready telcom and wireless infrastructure -- are probably far more important than todays mobile tools-de-jour. There is much work to be done, still - but not necessarily by white middle-class individuals working for development projects in the global North.