Warning:
This wiki has been archived and is now read-only.

Mw4d tools

From Mobile Web For Social Development (MW4D)
Jump to: navigation, search


MW4D Tools

Synopsis

It is critical to develop a real landscape analysis, investigating the exact domain of applicability of the different tools, how they relate one to another, what is their target audience, what are their requirements for usage, etc. As part of these investigations, the growing importance of social networks such as twitter or facebook in developing countries and their potential roles in social development will be studied. This document will define a methodology to review mobile tools available for the different technologies, develop a landscape analysis based on the definition of taxonomy or matrix of factors to consider to select a tool. The document will also identify gaps, in software, features or standardization, that prevent more people from deploying content and services.

January 2011 The methodology described in this document is currently tested on Data Collection Tools and SMS Gateways

Criteria for Tool Selection

For the purpose of these discussions, we have defined three terms to clarify the more generic term of "tool".

  • A tool: This is a software+hardware solution that implements some functionality, which can be deployed in multiple scenarios (eg, frontlineSMS, or Ushahidi). Note that a tool can be a sub-component of another tool. For example, it could be a library or plug-in that can be used to enhance other tools but should also be evaluated on its own as there may be other competing libraries or plug-ins that provide similar functionality.
  • A project: This is a scenario, story or deployment of said solution (eg, government programme in Mongolia to disseminate public health information, using frontlineSMS, or haiti.ushahidi.org).
  • A technology: This is a technology on which a project (above) is based (eg, SMS or Web application)

So we could write that:

  • CGNet Swara [1] is a project, based on a tool called AudioWiki [2], using Voice (IVR) and SMS technologies.
  • Honduras Health Mapping [3] is a project, based on a tool called Ushahidi [4], which is based on Web application and email technologies.

1. [1] http://news.bbc.co.uk/2/hi/8617943.stm 2. [2] http://groups.csail.mit.edu/commit/papers/08/kotkar-hci08.pdf 3. [3] http://hondurashealthmapping.crowdmap.com 4. [4] http://www.ushahidi.com

Tool Review Methodology

The list of criteria below is a work in progress and reflects initial discussions amongst group members.

Criteria specific to organizations using or deploying the tool

Criteria Possible values or sub-criteria Notes
Category
  • SMS
  • MMS
  • mobile web
  • voice
  • service
Type of service Type of services provided
  • infrastructure type of tools e.g. sms hub, voice platform
  • task specific e.g. market prices type of tool
  • authoring tools e.g. CMS, html auhtoring tool
Sector
  • healthcare
  • education
  • agriculture
  • government
Use case Addition of this field was recommended at the meeting on the 23rd to augment the 'sector' category. This could be a standalone value or, a sub-value to the chosen value in Sector (i.e. choose 'healthcare' then, choose use cases specific to healthcare)
Transport layer
  • voice (voice XML, other voice)
  • signaling (SMS, USSD)
  • data connection (mobile web, other data)
Initial cost of tool What is the cost structure?
  • none
  • one-off cost
  • subscription

Are there associated tools or components required?

  • software e.g. certain type of server and libraries
  • hardware e.g. a Mac, Linux
  • network capability e.g. 3G, Brew
  • operator specific capability
Long-term costs and infrastructure
  • electricity e.g. computers, servers running 24 hrs a day
  • internet access (what speed?)
  • hosting
Operator independence
  • does it need authorization and partnerships with operators?
  • does it work accross multiple operators?
  • does it work across multiple networks standards?
License
  • Is the tool (or aspects of it) open source?
  • Are there license restrictions?
Deployment time Time required to learn, set up, and deploy the tool e.g. days, weeks, months
Roadmap
  • Are plug-ins or additional components available?
  • Are new features planned?
  • Is the tool relatively future-proof from a technology point of view?
Existing user base
  • How many existing users/deployments?
  • Are there case studies available?
Required skills for deployment
  • technology skills
  • programming languages
  • other skills to operate or deploy the tool.
Maintenance Resources required to maintain the tool or service.
  • frequency of maintenance
  • frequency of software updates (if provided by the tool creator)
  • skills required for updates or maintenance e.g. does this require a specialist?
  • time e.g. wordpress updates are provided by the creators however each update requires time to install, adjust settings, verify nothing has broken etc.
Documentation
  • Is documentation available?
  • Is it comprehensive?
  • It is multilingual?
  • Is it online or offline?
  • Who is the target audience? e.g. end-users vs those who deploy the tool
Content requirements Is additional content required for this tool to function effectively? Trying to capture external costs that might be related to the tool. An example might be, an open source server that sends SMS updates, but would require some 3rd party (e.g. health practitioners) to create the SMS content at regular intervals.
Audience What audience can be served using this tool?
  • age
  • region (if relevant)
  • spoken language
  • literacy level (language, numeracy, technology)

Criteria specific to end-users

Criteria Possible values or sub-criteria Notes
End-user costs If the output of this tool requires interaction by end-users, what are their costs?
  • cost per use
  • time required to learn the user interface
  • literacy skills e.g. requires user learn considerable new terminology
  • technology costs e.g. requires user own a particular handset, platform device, or SIM from a particular operator
 Some of these may best be captured elsewhere
End-user constraints (technology/lifestyle)

SIM

  • prepay
  • post-pay

Payment type

  • operator
  • credit card

Data plan

  • yes
  • no

External computer (e.g. for side loading)

  • yes
  • no
 These values are not mutually exclusive.
End-user requirements (client/interaction layer) type of requirements on the user side
  • working on existing phone client application e.g sms client, mms client, phone client
  • needs a general client that can be present or downloaded e.g. web browser
  • tool-specifc download e.g. dedicated java application
 Should we break browser requirements down even further? e.g. web browser -> WAP, XHMTL-MP (what version), HTML/XHTML, WAP CSS vs CSS, WML Script vs ECMA etc.
End-user requirements (handset) type of phones required
  • any mobile
  • feature phones
  • smartphones
 Need to establish criteria for each category given that these industry terms are in transition. "Any mobile" probably implies any device capable of making a call, but what about SMS, MMS?
End-user training How easy is it for users to start using this tool.
  • common or existing skills (e.g. sending a SMS)
  • training required
 May not be the best values but seems important to capture whether users can acquire the necessary skills in their community as opposed to requiring some formal training resources.

Contributors

  • StephanieR
  • StephaneB
  • BettyP
  • ChristelleS
  • RaphaelD
  • ShwetankD

Content

Retrieved from "https://www.w3.org/2008/MW4D/wiki/index.php?title=Mw4d_tools&oldid=1044"