Category — Mobile apps development
Exactly ten years ago this month I was preparing for my first ever piece of work in mobile, two years of work which would lead to the development of an innovative conservation service in 2003 – wildlive! – and the release of one of the earliest reports [PDF] on the application of mobile technology in conservation and development in 2004. A lot has happened since then, not least an explosion in interest, buzz, excitement – and, yes, hype – and a sense that mobile can be the saviour of, well, everything. Back then you’d likely be able to fit everyone working in mobile-for-development (m4d) into a small cafe. Today you’d need at least a football stadium. m4d – and it’s big brother, ICT4D – have become big business.
Not that I needed more proof of mobile’s status at development’s top table, earlier this week I attended Vodafone’s “Mobile for Good” Summit in London. It was a high-profile affair, and an extremely upbeat one at that. I left with mixed feelings about where m4d is headed.
My five takeaways after a day of talks, debates and demonstrations were:
1. Everyone is still excited by the potential of mobile
2. The same projects surface over and over again as proof mobile works
3. Mobile is still largely seen as a solution, not a tool
4. It’s up to the developed world to get mobile working for the poor
5. The top-down mindset is alive and well
Suffice to say, all of these conclusions troubled me as I sat on the train home.
I’ve been thinking for some time about the future of m4d, and how far we’ve got over the past ten years or so. I’ve written frequently about the opportunities mobile technology offers the development community, and my fears that we may end up missing a golden opportunity (see “Time to eat our own dog food?” from March 2009). I’ve long been a champion of platforms, and understanding how we might build tools for problem owners to take and deploy on their own terms. Yes, we should provide local entrepreneurs and grassroots non-profits with tools – and where appropriate and requested, expertise – but we shouldn’t develop solutions to problems we don’t understand, we shouldn’t take ownership of a problem that isn’t ours and we certainly shouldn’t build things thousands of miles away and then jump on a plane in search of a home for them.
But this is still, on the whole, what seems to be happening. And this, I’m beginning to believe, is rapidly becoming ICT4D’s “inconvenient truth”.
A fulfilled future for ICT4D (of which m4d is an increasingly dominant part) is not the one I see playing out today. It’s future is not in the hands of western corporates or international NGOs meeting in high-profile gatherings, and it’s not in our education establishments who keep busy training computer scientists and business graduates in the West to fix the problems of ‘others’. The whole development agenda is shifting, and my prediction for the future sees a major disconnect between what ‘we’ think needs to be done, and what those closest to the problems think needs to be done. Call it “disruptive development“, if you like. As I told the Guardian in an interview earlier this month:
The rise of homegrown solutions to development problems will be most crucial in future. That means African software developers increasingly designing and developing solutions to African problems, many of which have previously been tackled by outsiders. This, I think, will be the biggest change in how development is ’done’
I’m not the only person to be saying this. Many good friends working at the intersection of African development and technology have been doing the same for some time. The real change, and the big difference, is that it’s finally happening. A message which was previously given in hope, a message that was previously given out of an inherent belief that there was a better, more respectful and appropriate way of doing things, is now becoming reality. ICT4D is changing, and the balance of power is changing with it.
FrontlineSMS has always spoken to an approach I’ve long believed in, one where users are empowered to develop solutions to their own problems if they so wish. There are many reasons why FrontlineSMS continues to work – the decision of the new Management Team to shift software development to Nairobi is one of the more recent ones. But fundamentally it’s about what the platform does (and doesn’t do) that really resonates with innovators, entrepreneurs, non-profits and problem owners across the developing world. As the Guardian put it in the recent article, “As open-source technology for mobile platforms, innovations like FrontlineSMS are essentially a blank canvas for grassroots organisations to apply to any local context”.
That local context is becoming increasingly vibrant as university students across Africa graduate with Computer Science and Business Management degrees; as innovation hubs spring up across the continent meeting a growing, insatiable demand for places to meet, work and network with like-minded problem solvers and entrepreneurs; and as investors launch funds that show they’re starting to take young African tech startups seriously.
This activity hasn’t escaped big business. Google, IBM, Microsoft, Nokia, Hewlett Packard and Samsung have been opening offices across the continent, snapping up much of the talent in the process (ironically often at the expense – and despair – of locally-based NGOs). But while technology businesses take note and develop local capacity that enables them to develop more appropriate local solutions, the broader development ‘community’ seem trapped in an older mindset of technology transfer.
Technology transfer, of course, is big business – there’s no shortage of donor money out there for projects that seek to implement the latest and greatest proven Western innovations in a development context, and there are countless tens of thousands of jobs that keep the whole machine running. A lot has to change if the development community is to face up to all its new realities, yet it’s looking more likely that the destiny of the discipline lies in the hands of the very people it originally set out to help.
So, if the future of ICT4D is not university students, NGOs or business graduates devising solutions in labs and hubs thousands of miles away from their intended users, what is it?
Well, how about something a little more like this?
It seems rather obvious to put a local technology entrepreneur on a bus and have him chat to a rural farmer, but imagine what might be possible if this approach became the “new ICT4D”, not that the entrepreneur or the farmer would see it as that, or ‘development’ at all. You can see more of the fascinating TV series which linked local technologists to local problems on the TVE website. There’s a lot that’s right with this approach, particularly if you consider what would usually happen (hint: it involves planes).
I’m not usually one for making predictions but it is that time of year, after all, and it is my ten year anniversary in mobile. So here’s a biggie.
Development is changing, powered by accessible and affordable liberating technologies and an emerging army of determined, local talent. A local talent that is gradually acquiring the skills, resources and support it needs to take back ownership of many of its problems – problems it never took original ownership of because those very skills and resources were not available.
Well, now they are. The ICT4D community – education establishments, donors and technologists among them – need to collectively recognise that it needs to ajdust to this new reality, and work with technologists, entrepreneurs and grassroots non-profits across the developing world to accelerate what has become an inevitable shift. Or it can continue as it is, and become increasingly irrelevant. “Innovate or die” doesn’t just apply to the technologies plied by the ICT4D community. It applies to the ICT4D community itself.
[This post was edited down and republished in the Stanford Social Innovation Review in January 2013 here].
December 12, 2012 128 Comments
In many sectors of international development it’s hard to imagine how you’d have much impact if you weren’t out in the field. After all, teachers want to be in-class. Doctors want to be in-clinic. And conservationists want to be in-situ. There’s only so much any of them can do when they’re not. Getting ‘stuck in’ is largely what it’s all about.
So why are so many ICT4D professionals happy to work remotely? And why does much of the ICT4D sector not find that odd?
In an article due to be published this week on BBC Future, I write about how technology has ‘democratised development’ and that there are “likely more people working on solving social and environmental problems in the world today than ever before in human history”. The spread of mobile technology and the Internet has made all of this possible. These are exciting times, make no mistake.
But just because these tech-based opportunities have literally come to us in the comfort of our own homes, we mustn’t kid ourselves into believing that we don’t need to make any effort to lay the groundwork to our apps and ideas by getting out and spending time in the field. Just because the very technologies we use, by their very nature, allow us to work at-a-distance – remotely – that doesn’t mean we have to. If that doctor, or teacher, or conservationist could do their work without stepping into that Malawian clinic, or Lusaka classroom or Namibian national park, would they? I doubt it.
Last night I caught sight of a tweet from Tony Roberts. Although it sounds like something an anthropologist (or philosopher) might say, it perfectly describes an approach the ICT4D sector might like to adopt.
The beauty of the Internet, and the spread of mobile technology, is that anyone anywhere can quickly develop and distribute a mobile-based solution to a social or environmental problem, and start picking up users immediately. The technology is in place, and the distribution channel is there. All that’s needed are good, solid ideas and a drive and passion to fix a problem somewhere – and, let’s face it, there are plenty of those. All-in-all, the barriers to entry are lower than they’ve ever been.
But they’re so low we end up with a different problem.
For the doctor, teacher or conservationist, understanding the context of their patient, student or endangered species is critical for the work they do if they’re to do it well. With few exceptions, they can only get that by spending time in the field. This isn’t perceived to be the case for a programmer or coder. The result? A majority of apps written in isolation which have little chance of success.
Maybe that doesn’t matter. With the barriers to entry so low the cost of building and distributing these apps is minimal. The fact that so many people are taking an interest in fixing things should be encouraging enough. But there’s no doubt that spending time with your users, understanding their context, discussing what they need and then building a tool based on all of those things gives you the greatest chance of success.
August 27, 2012 53 Comments
“Two weeks ago, I was staying at a working dairy farm sixty kilometers north of Bogotá, Colombia. I was fiddling around with my iPad when one of the kids that worked in the stables came up to me and started staring at it. He couldn’t have been more than six years old, and I’d bet dollars to donuts that he had never used a computer or even a cellular telephone before (Colombia has many attractions. The vast pool of illiterate poor is not one of them)
Curious, I handed him the device and a very small miracle happened. He started using it. I mean, really using it. Almost instantly, he was sliding around, opening and closing applications, playing a pinball game I had downloaded. All without a single word of instruction from me”
Michael Noer, “The Stable Boy and the iPad“
Two questions scream out at me when I read this. Firstly, what would happen if Apple turned a fraction of its attention to ICT4D? And secondly, why don’t Apple work in ICT4D? In a sector where so many tools and solutions seem to fail because they’re too complex, poorly designed, unusable or inappropriate, who better to show us how it should be done than the masters of usability and design?
The answer to the second question is a little easier to answer than the first. As Walter Isaacson pointed out in his recent biography, Steve Jobs felt he could contribute more to the world by ‘simply’ making brilliant products. He seemed to have little time for philanthropy, at least publicly, and his laser focus meant he saw almost everything other than Apple’s mission as a distraction. Ironically, had he decided to give away some of his ballooning wealth, he’d most likely have funded programmes working in nutrition and vegetarianism, not technology, according to Mark Vermilion (who Steve Jobs hired back in 1986 to run the Steven P. Jobs Foundation, which he was destined to shut down a year later).
Had Steve Jobs decided to pursue his Foundation, and had he decided to fund technology-based initiatives in the developing world, how well might he have done, and what might Apple have been able to contribute to our discipline?
Here’s five initial thoughts on where an Apple approach to ICT4D might be different – or problematic.
1. Consult the user
One of the central tenets of ICT4D is to consult the user before designing or building anything. In business, at least, Apple don’t do this. They certainly didn’t speak to Colombian farm children, yet they managed to intuitively build something that worked for the six year old Michael Noer met. As Steve Jobs famously said:
Our job is to figure out what users are going to want before they do. People don’t know what they want until you show it to them. That’s why I never rely on market research. Our task is to read things that are not yet on the page
An Apple ICT4D project would unlikely spend much time, if any, speaking with the target audience, an approach entirely at odds with the one we champion right now.
2. Customer vs. beneficiary
Apple would see people as customers, and they’d be carrying out what they’d see as a commercial transaction with them. This approach would mean they’d have to build something the customer wanted, and that worked (and worked well). Since it would have to sell, if successful it would by default be financially sustainable. Part of the problem with the largely subsidised ICT4D “give away technology” model is that no-one is ultimately accountable if things don’t work out, and regular business rules do not apply.
3. Open vs. closed
The ICT4D community is entrenched in an open source mindset, almost to the extent that closed solutions are scorned upon. Steve Jobs was a strong believer in controlling all aspects of the user experience, all the way from hardware through to software. To him, closed systems were better “integrated” and open systems “fragmented”:
What is best for the customer – integrated versus fragmented? We think this is a huge strength of our system versus Google’s. When selling to people who want their devices to just work, we think integrated wins every time. We are committed to the integrated approach. We are confident it will triumph over Google’s fragmented approach
There is no evidence in ICT4D, I don’t believe, which points towards more success for open solutions vs. closed (however you define success), yet open remains dominant. An early Apple success might give us pause for thought.
4. Time for the field
Although Paul Polak doesn’t work in ICT4D, he is one the biggest proponents of “getting out into the field to understand the needs of your customer”. In his long career he’s interviewed over 3,000 people earning a dollar or less a day to better understand their needs – and the market opportunity. In this short video he talks about the process of spending time in rural villages, talking in depth with villagers, and identifying opportunities for transformative impact.
Apple wouldn’t see the need to do this because they wouldn’t consider the needs of dollar-a-day customers as being any different to anyone else. They’d consider their intuitive design and user interface to be non-culturally specific. People, everywhere, want simple-to-use technologies that just work, regardless of who they are.
5. Appropriate technology
Apple’s product line hardly fits into the appropriate technology model – they’re expensive, power-hungry and the devices are reliant on a computer (via iTunes) as their central controlling “hub”. The systems are also closed, blocking any chance of local innovation around the platform. How Apple tackle this – yet maintain their standards of excellence in design and usability – would probably turn out to be their biggest challenge.
Although it hasn’t happened yet, a post-Steve Jobs Apple might yet develop a philanthropic streak. If they did they could easily turn to their friends at frog design (now branded Frog) for help. Frog, who worked closely with them in the early days of the Macintosh range, have recently worked with a number of ICT4D initiatives and organisations, including Project Masiluleke and UNICEF.
Apple have already reinvented the music and publishing industries. With the talent, capital and resources available I’d bet my bottom dollar on them reinventing ICT4D if they chose to. Steve Jobs liked to “live at the intersection of the humanities and technology”, and that’s exactly the place where ICT4D needs to be.
January 24, 2012 116 Comments
“If you were thinking of designing or building a website, you’d be in luck. If you were thinking of writing a suite of financial management tools, you’d be in luck. If you were even thinking of creating the next big video game, you’d be in luck. Visit any good bookstore and the selection of self-help books and “how-to” guides leave you spoilt for choice.
Unlike the plethora of self-help guides on the more established topics, if you were looking to do something with mobile phones you’d likely have mixed results. There are plenty of books available extolling the virtues of Java, Python, Ruby, Ruby on Rails, C++, Symbian, Android and just about any other development environment or platform out there. Combine that with the growing field of mobile UI (user interface) design and you’d think that pretty much everything was covered. But there is one thing missing, although you’d probably only notice if you’re one of a growing number of developers turning their attention to the developing world”.
I’m talking about a guide on “Building Mobile Applications for Social Good“. Although just a start, this article – written for The Testing Planet – in part aims to fill that gap. At conferences and seminars I often talk about our experiences developing FrontlineSMS, and the thinking and fieldwork behind it, but until now much of this wasn’t particularly well captured in written form in a single place.
A PDF of the “Building Mobile Applications for Social Good” article is available via the kiwanja website here [2 Mb]. A PDF of the full edition of this month’s Testing Planet is available on their website here.
The Testing Planet is a magazine produced by The Software Testing Club and its community members. The magazine is published in print, ebook, Kindle, PDF and web format. You can follow them on Twitter at @testingclub
November 29, 2011 80 Comments
We were excited to join colleagues and friends in Washington, DC, on Tuesday 9th August to release the first edition of our “User Guide on Data Integrity”, a tool that will help FrontlineSMS users around the world better understand the flow of information into and out of the platform, the risks and vulnerabilities to that data, and simple ways they can mitigate those risks.
Review by Cathryn Paine reposted from the FrontlineSMS blog
To kick off the discussion around the new guide, we hosted a panel discussion at Johns Hopkins’ School of Advanced International Studies, where FrontlineSMS’ Sean McDonald joined Jon Gosier of metaLayer, Development Seed’s Paul Goodman, and Internews Vice President for New Media Kathleen Reen, who moderated the event. This research effort, based on FrontlineSMS user input and research by Kristina Lugo and Carol Waters, focused not on mobile system security, a critical issue better addressed by others, but more on the ways that contextualized program design and implementation can improve data quality and reduce user risk. Above all, we learned through the process, context is key. Understanding the needs and norms of the target population, and the goals of the project itself, is vital in determining the proper tools and approach to designing a FrontlineSMS workflow that can achieve those goals.
The panel discussion centered on these key points, especially the role that stakeholders play in the reliability and integrity of project data. Issues from misinterpretation, to unconscious bias, to lack of corroboration can creep into an improperly designed data collection effort, polluting the entire dataset in the process. To mitigate these threats, Jon emphasized focusing on localization and usability in project design—understanding the users or beneficiaries of a project is the best way to minimize human error and maximize data integrity.
Paul Goodman during a project planning session, sketching out project workflow which includes FrontlineSMS use. Photo credit: Paul Goodman
Paul contextualized these points with insights from mobile projects in Haiti and Benin, focusing on the process of implementing new technologies—from design to training to implementation. Particularly, the panel discussion focused on assuming that program data would be made public, in an effort to design projects that achieve important goals while minimizing risks associated with data sharing or system compromise.
Throughout the conversation, the discussion kept coming back to the importance of user-focused, context-aware approaches and resources in ICT projects. No matter how complicated the technology, an informed and engaged community of project staff and participants is really the best tool for safeguarding quality data. All in all, a great discussion that we hope to keep going through the forum and ongoing interactions!
You can download a PDF of the FrontlineSMS User Guide on Data Integrity here.
August 11, 2011 32 Comments
“After all is said and done, a lot more will be said than done” -
Twitter has been abuzz lately with fascinating snippets of advice on how to succeed, how not to fail, what makes a good social venture, what makes a good mobile project or how to be a successful social entrepreneur. Of course, it’s easy to say these things, and even easier to repeat mantras and slogans which fit a popular or emerging philosophy. Who could argue, for example, that “users should be put first”?
Sadly, when all is said and done, the reality is that it’s still much easier to ignore the advice and go do your own thing your own way, rather than doing things the right way.
The best way to get a sense of the true philosophy – the DNA – of a project is to see if it passes a “taste test”. This is particularly true in mobile, where almost all initiatives claim to have engaged or active communities, or to empower, to put users first, or to have been ‘born’ in the field. The question is: Does the rhetoric actually match the reality? In an age where more and more projects are coming under increasing scrutiny, ensuring they are properly positioned is crucial.
It’s quite easy to determine whether or not a tool is going to be of any use to an end user (an NGO in this case), or whether you’d need a medium to high degree of technical literacy to make use of it (in which case you might argue that the tool was more developer-focused). For some time I’ve used the concept of the “social mobile long tail” to graphically represent this.
In short, tools in the red area are technically and financially out-of-reach of many grassroots NGOs, many of whom sit in the green space. Tools at the higher end of the graph are generally more complex, server-based systems which require a high degree of technical competence, and often the Internet, to set up and use. Tools in the lower end are simple, low-cost, need few technical skills, work on easily available hardware, don’t require the Internet, and are easy to install and run. Tools in the green space can be quickly adopted and replicated – within hours – whereas tools at the other end need much more planning, i.e. more people and more lead time, and most likely a degree of training.
So, how might we determine where a tool should be placed on the “social mobile long tail”? There are likely many measures and metrics, but I’d say these are a few of the more obvious ones the user would be principally concerned with:
- Does the project have a user-facing, NGO-friendly website?
- How technical is the language on the site?
- Is there an easily accessible, open, visible user community?
- How easy is the software to find, download and install?
- Will it work on widely available hardware and software in the places where it will be used?
- Can the user independently deploy the tool if they want to?
For some time I’ve wondered whether it would be worth scoping out the mobile landscape and plot available tools along the tail. Not only would it satisfy my general curiosity, but it could be immensely valuable to an NGO community which still largely struggles to understand the mobile technologies they believe – and hope – they should be using.
October 14, 2010 15 Comments
Date: Monday 20th September, 2010
Venue: London School of Economics
Speakers: Dr Jenny Aker, Ken Banks, Dawn Haig-Thomas
Chair: Diane Coyle
IGC Growth Week 2010 Public Discussion
“Mobile phones have the potential to contribute significantly to economic growth in the developing world, in both the private and public sector. From improving market information for fish traders in Lake Victoria, to enabling medical outreach services in rural South Asia, the mobile is a versatile and adaptable tool. What impact can mobiles have on those previously excluded from financial services and communications networks? Which policies will help turn the promise of mobiles into real benefits for the poorest people?
This session, moderated by Diane Coyle, OBE, of Enlightenment Economics, features a panel of researchers and practitioners sharing ideas and experience from the field, discussing a range of case studies from literacy and conditional cash transfer programs in Niger to SMS-based communications for rural hospitals in Malawi”.
Jenny Aker is assistant professor of development economics at The Fletcher School of International Affairs, Tufts University.
Ken Banks is the founder of FrontlineSMS and kiwanja.net.
Dawn Haig-Thomas is director of the GSM Association Development Fund.
Further details of the event, including an audio version of the discussion, are available on the London School of Economics website.
October 10, 2010 38 Comments
Do the majority of people working in “mobiles for development” work in mobile, or development? It may seem like an odd question, but how people approach “m4d” may have more of an impact on success or failure than we think.
The world of social mobile isn’t short of anecdotes. “Put the user first”, “Consider the technology only at the very end”, “Don’t re-invent the wheel” and “Build with scale in mind” are just a few. Ignore these and failure won’t be far around the corner, we’re told. But maybe we’re missing something here. Sure, there’s a growing number of ‘best’ practices, but one thing we rarely seem to question are the very credentials of the project origin itself.
Everyone from donors to project managers and technologists to journalists are keen to identify traits or patterns in ‘failed’ mobile projects. Many of their conclusions will point to poor planning, poor technology choice or lack of collaboration, but sometimes the biggest failure may have taken place long before anyone got near a mobile phone.
What I wonder is this. Do we know what ratio of “m4d” projects are initiated by development practitioners (or sectoral experts in health, agriculture, conservation and so on) as opposed to mobile technologists, and what impact does this have on the success or failure of the project? In other words, if the problem solver is primarily a mobile technologist – the “m” part of “m4d” – then you might assume they have much less understanding of the on-the-ground problem than a development practitioner or sectoral expert might – the “d” part.
Does this bear out in reality? If failure does turn out to be higher among technologists then this is a relatively easy problem to fix, whereas many of the other perceived reasons for failure are not. It’s all about getting back to basics.
(Click here for more observations on mobile development).
I’ve always maintained that the people closest to the problem have the best chance of coming up with a solution, and this probably bears out in many cases, particularly in the ICT4D field. Ushahidi, started by Kenyans to solve a Kenyan crisis – and DataDyne, a health-based data collection solution designed by a paediatrician - immediately spring to mind. In these instances, being up-close and dirty with the problem came well in advance of any technology-based solution to it. The same goes for our very own FrontlineSMS initiative, borne out of a series of visits to South Africa and Mozambique back in 2003/2004.
In any discipline, the greater the rate of innovation the greater the problem of focus, and mobile is no exception. As Bill Easterly put it in a recent post in response to questions from students about how they might help “end world poverty”:
Don’t be in such a hurry. Learn a little bit more about a specific country or culture, a specific sector, the complexities of global poverty and long run economic development. At the very least, make sure you are sound on just plain economics before deciding how you personally can contribute. Be willing to accept that your role will be specialized and small relative to the scope of the problem. Aside from all this, you probably already know better what you can do than I do
This is great advice, and not just for economists. If mobile and health is your thing, focus on health and get very good at it. If it’s mobile and agriculture, or mobile and election monitoring, do the same. Whatever your area of interest, get out and understand the issues where they matter – on the ground – and don’t get totally sidetracked by the latest trends, technologies or disciplines. Whatever the reason for your interest in ‘mobiles for development’, make sure you don’t forget the importance of understanding the ‘development’ bit.
Focus is highly underrated, and often debates around technology choice, open source, challenges of scale and “understanding your users” are distractions from a much-less discussed but equally vital question. And that’s this.
“Who’s best placed to run a successful “m4d” project – the m‘s or the d‘s?”.
August 13, 2010 66 Comments
Although I find myself intrigued by the convergence of computer science, human computer interaction (HCI) design and international development, it’s not often that I find myself in a room of experts. They’re just not places I tend to mix, most likely because I have no professional IT qualifications, let alone a computer science degree, and I’ve done most of my own software design off-the-cuff, much to the dismay of people who hoped there was a robust process behind it.
Last August I got my first taste of the very real challenges that the computer science world faces when it comes up against the equally real challenges of international development. The meeting – convened at UC Berkeley – was an eye-opener for me to say the least, and as I left I blogged about how thankful I was that it wasn’t me who had to come up with the answers. You can read that post here.
A little later in the year I was invited to speak at the First International Workshop on Expressive Interactions for Sustainability and Empowerment, held at one of Vodafone’s London offices. The topic of conversation was similar, but here the focus was on how to build mobile tools that work in difficult, challenging, ‘foreign’ environments. Following my talk I was invited by the Editor of Interfaces, John Knight, to contribute an article to the next edition of their magazine.
For the article I teamed up with Joel Selanikio, co-founder of DataDyne.org and the creator of the EpiSurveyor mobile data collection tool. It made sense working with Joel for a number of reasons. Not only have I known and admired him and his work for some time, but Joel is first and foremost a paediatrician. For him – like me – understanding the problem takes priority over the technology, consideration of which should always come last. FrontlineSMS and EpiSurveyor have both evolved from time spent in the field – observing, experiencing and understanding before designing, developing and building.
You can read our thoughts on the process – “Ten things you might want to know before building for mobile“ – in the current edition of Interfaces magazine (PDF, 2.5Mb).
January 10, 2010 35 Comments
After three workshops on three continents, conversations and meetings with countless NGOs, academics, researchers and technologists, and many hours of conference calls, W3C this week released their “Mobile Web for Social Development Roadmap”, a comprehensive document which sits at the heart of the wider work of the Mobile Web for Development Interest Group (MW4D).
According to the Roadmap document, its purpose is to help:
“… understand the current challenges of deploying development-oriented services on mobile phones, evaluate existing technologies, and identify the most promising directions to lower the barriers of developing, deploying and accessing services on mobile phones and thereby creating an enabling environment for more social-oriented services to appear”
The Roadmap is split into two distinct sections. The first covers challenges and issues in developing mobile tools for social development, and the second looks specifically at technology options. The primary audience are individuals, organisations and entrepreneurs interested in social mobile; the mobile industry itself; academics; international organisations and, finally, policy makers and regulatory bodies.
The Roadmap is very much a work-in-progress, and the MW4D Interest Group welcomes comments, recommendations and suggestions to help shape it as the work moves forward.
December 3, 2009 23 Comments