This document is also available in non-normative formats such as PDF.
Copyright © 1998-2009 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This document is the heart of the MW4D IG work. Its purpose is to 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.
This document is divided into two major parts. The first part presents the
major challenges today for both developing and accessing mobile services,
potential ways to bridge them with existing tools, technologies and
infrastructure, and potential research directions to follow to provide a more
comprehensive resolution or solution. The second part focuses on presenting the
major technologies and the major options existing today to deploy content and
applications on mobile phones. For each of these technologies, the document
presents a short analysis of the technology's potential and the requirements in
terms of infrastructure, devices, targeted end-users, and costs associated with
implementation and delivery.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This is a public Interest Group Note produced by the Mobile Web for Social Development Interest Group, which is part of the Mobile Web Initiative. This publication as an Interest Group Note represents the completion of the first charter of group work. The contents of this document may be subject to further iteration and development. Please send comments to<EMAIL_ADDRESS>(publicly archived).
Publication as an Interest Group Note does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. The group does not expect this document to become a W3C Recommendation. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
The disclosure obligations of the Participants of this group are described in the charter.
This section summarizes the major findings described within the document, and gives an overview of the different actions recommended. The document has two major objectives: firstly, to identify challenges that have an impact on either developers or users of mobile services and content, and secondly to investigate the potential of existing technologies to meet (at least some of) these challenges. The technologies considered in the scope of this document are split into three categories, depending on the type of infrastructure required. Indeed, networks can offer up to three channels of communication.
NB: In this document, the term 'channel of communication ' will be used instead of the more appropriate technical term [196]bearer services which might be less clear for non-technical readers, or non-specialists.
For each of the identified challenges in the roadmap, we investigate how it is handled by each of the technologies working on these different channels.
This document has two major objectives to identify challenges that are impacting either developers or users of mobile services and content, and to investigate the potential of existing technologies to meet (part of) these challenges. The following tables summarize the findings of this roadmap. The first table compares the abilities of the different technologies to meet the user-related challenges. The second compares the abilities of the different technologies to meet the author-related challenges.
People with Disabilities |
People with low reading skills |
People speaking lesser-known languages |
People without computer literacy |
Costs (for the end-user to access the service) |
Infrastructure |
Handset |
|||
|
Predictability |
Amount |
||||||||
|
Voice Channel |
VoiceXML |
[Accessible]
Ok for people with Visual Impairment |
[Accessible]
Ok |
[Accessible] Ok for pre-recorded audio file / issues with Text-to-speech and speech recognition engines |
[Existing Applications can be aggregated]
No discoverability (1) mechanism/Works with portals |
[Predictable cost]
Same as voice call |
[Expensive]
Usually more expensive than SMS (3) |
[No requirements] Works on all telephony networks |
[No Requirements]
Works on all phones, even not mobile |
|
Other Voice Applications |
[Accessible] Ok for people with Visual Impairment |
[Accessible]
Ok |
[Accessible]
Ok for pre-recorded audio file / issues with Text-to-speech and speech recognition engines |
[Aggregation hardly possible]
No discoverability mechanism (1)/Doesn't work with portals |
[Predictable cost] Same as voice call |
[Expensive]
Usually more expensive than SMS (3) |
[No requirements]
Works on all telephony networks |
[No requirements] Works on all phones, even not mobile |
|
|
Signalling Channel |
SMS |
[Depends on the Handset] Depends on the accessibility of the operating system of the handset |
[Not Accessible]
only text representation |
[Poorly Accessible]
depends on the handset and the network. Very few operators supports appropriate encoding |
[Aggregation hardly possible] No discoverability (1) mechanism/Doesn't work with portals |
[Predictable cost] Same as SMS |
[Potentially Expensive]
Relatively expensive depending on the application |
[No requirements]
Works on all mobile networks |
[No requirements]
Works on all phones |
|
USSD |
[Depends on the Handset]
Depends on the accessibility of the operating system of the handset |
[Not Accessible]
Only text representation |
[Poorly Accessible] Depends on the handset and the network. Very few operators supports appropriate encoding. |
[Aggregation hardly possible]
No discoverability (1) mechanism/Doesn't work with portals |
[Free]
Free |
[Free]
Free |
[No requirements]
Works on all mobile networks |
[No requirements]
Works on all phones |
|
|
Data Channel |
Mobile Web |
[Depends on the Content Developer]
Ok if written in the right way following Web Content Accessibility Guidelines |
[Potentially Accessible] No guidelines available yet, but supports of icons and audio stream |
[Accessible] Infrastructure can support all languages of the World, but only few languages supported |
[Discoverable]
Discoverability (1) through search engines and portals |
[Not Predictable cost]
Not Predictable if not flat-rate plan |
[Not Expensive]
Usually at least 1000 times cheaper than SMS |
[Medium Requirements] Requires data service, GPRS minimum |
[Medium Requirements] Needs at least a java stack |
|
Other data-service based applications |
[no support]
No default support of assistive technologies or accessibility interface on the phone |
[Potentially Accessible]
No guidelines available yet, but potential supports of icons and audio stream |
[Problematic] Depends on the handset, and the appropriate implementation of the applications. |
[Aggregation hardly possible] No Discoverability (1) / on some platforms, application stores (2) |
[Not Predictable cost]
Not Predictable if not flat-rate plan |
[Not Expensive] Usually at least 1000 times cheaper than SMS |
[Medium Requirements] Requires data service, GPRS minimum |
[Medium Requirements] Needs at least a java stack or an operating system APIs |
(1)Discoverability: The ability for user to use tools to automatically find existing services, content or applications. The existence of search engines on the Web enables potentially all resources to be found by any users without external intervention
(2)Application stores: Digital distribution platforms for mobile devices. The application store is a service accessible directly from the phone as a specific application that allows users to browse and download applications. These applications are available to purchase or free of charge, depending on the application. The applications are downloaded directly to the phone.
(3)Usually the price of one SMS is equivalent to a voice call of around 10 to 30 second duration (national number, depending on intra/inter networks calls)
Author-related Challenges
Expertise |
Tools |
Monetization of services |
Costs (for the content author) |
Deployment |
||||||
|
Platform-level tools (1) |
Application-level tools (2) |
Hosting |
Delivery |
Discoverability (3) |
End-user Training |
|||||
|
Voice Channel |
VoiceXML |
[Medium expertise required ]
No usability guidelines - but easy to use/easy to understand markup language |
[Tools exist]
Free voice browsers, standalone or as extension for asterisk exists Voice development frameworks exist |
[No Tools]
No application-level tools exists yet |
[Possible but hard to implement ]
Possibility to use surtaxed phone numbers / no monetization option at the application level |
[Expensive]
Expensive infrastructure required but could be free if relying on a third-party infrastructure/hosting service |
[Free]
Free except if callback mechanism implemented |
[Existing Applications can be aggregated]
No discoverability (3) mechanism / Works with portals |
[No Training Required]
Very easy to use for non-trained end-user |
|
|
Other Voice Applications |
[High expertise required] No usability guidelines / requires programming skills |
[Tools exist]
Free and open source tools available |
[No Tools] No application-level tool exists |
[Possible but hard to implement ] Possibility to use surtaxed phone numbers / no monetization option at the application level |
[Expensive]
Expensive infrastructure required |
[Free]
Free except if callback mechanism implemented |
[Aggregation hardly possible]
No discoverability (3) mechanism/Doesn't work with portals |
[No Training Required]
Very easy to use for non-trained end-user |
||
|
Signalling Channel |
SMS |
[Low expertise required]
Low expertise required on some SMS platforms |
[Tools exist]
Lots of free and open source tools |
[Few Tools exist]
Some application level tools available (mostly data collections) |
[Difficult]
Premium rate SMS service (4) available but difficult to implement cross-network and need deals with operators or other companies to setup |
[Relatively Expensive]
Requires at least a pc and a GSM modem or Web connection + Subscription to Bulk SMS provider |
[Expensive]
Cost of sending SMS is high for service providers |
[Aggregation hardly possible]
No discoverability (3) mechanism/Doesn't work with portals |
[Minimal training and Awareness Required]
Interaction at user's initiative / no way to know how to interact with the service. However people are used to use SMS client |
|
|
USSD |
[High expertise required] Programming skills required |
[No Tools] No free and open source tools available |
[No Tools]
No application level tools available |
[Difficult] No monetization possible except through the operator billing system |
[Relatively Expensive]
Requires at least a pc and a gsm modem |
[Free] Free |
[Aggregation hardly possible]
No discoverability (3) mechanism/Doesn't work with portals |
[Training and Awareness Required]
Interaction at user's initiative / no way to know how to interact with the service |
||
|
Data Channel |
Mobile Web |
[Low-expertise required]
Low expertise required, Free WYSIWYG authoring tools available |
[Tools exist]
Lots of free and open tools for support, development or authoring |
[Tools exist]
Few application level tools available |
[Possible] Classical ecommerce techniques available but no micropayment yet |
[Free]
Free hosting available |
[Free] Free |
[Discoverable]
Discoverability (3) through search engines and portals |
[Minimal Training Required]
Need configuration and training on using a browser, but then easy to use content |
|
|
Other data-service based applications |
[High expertise Required]
Requires programming skills |
[Few Tools exist]
Lots of free SDK (5) |
[Few Tools exist]
Few specific tools available |
[Possible] Nothing specific available except with Application Stores |
[Moderately Expensive]
Depends on the application, but usually rely on free web hosting solution |
[Free]
Free |
[Aggregation possible in some cases]
no Discoverability (3) / on some platforms, application stores (6) |
[Training Required]
Needs specific application user training |
(1)Platform-level tool: Platform-level tools enable the use of a particular technology in a completely free way, without any specific task focus. Examples of such tools are SMS Hub, HTML authoring tools or Voice Authoring tools.
(2)Application level tool: More advanced tools focusing on specific tasks or type of applications, offering advanced features, complex user interactions, or dynamic content, for authors without programming skills.
(3)Discoverability: The ability for user to use tools to automatically find existing services, content or applications. The existence of search engines on the Web enables potentially all resources to be found by any users without external intervention.
(4)SDK: Software Development Kit
(5)Premium SMS Service: A way to have an SMS charged at a rate higher than a regular person-to-person SMS. See [3]a detailed definition.
(6)Application stores: Digital distribution platforms for mobile devices. The application store is a service accessible directly from the phone as a specific application that allows users to browse and download applications. These applications are available to purchase or free of charge, depending on the application. The applications are downloaded directly to the phone.
Future Directions to explore
For each of the challenges identified in sections 6.1 and 6.2, the roadmap identifies future directions to explore or actions to launch. Those actions are of three types: R&D actions, Support Actions, Recommendations.
R&D Actions
R&D actions are proposed for challenges that require further research, investigations or standardization. The R&D actions suggested in the roadmap are the following:
Support Actions
The support actions are proposed for challenges that require actions of dissemination, capacity building or tools development. The support actions suggested in the roadmap are the following:
Recommendations
Recommendations are specific messages sent to specific actors or stakeholders of the domain. The roadmap makes the following recommendations:
This document summarizes the work done and discussions held in the W3C Mobile Web for Social Development Interest Group (MW4D) since June 2008 and in the two workshops organized [4]in June 2008, and [5]April 2009. The aim of the MW4D group is to explore the potential of Web technologies on Mobile phones as a solution to bridge the Digital Divide and provide Information and Communication Technology (ICT) based services to rural communities and underprivileged populations of Developing Countries. In the context of this document, the expression ' Mobile Web ' should be understood in its widest sense as accessing and interacting with Web content from a mobile phone. It is not limited to Mobile Browsing. The section Technologies defines the different technologies that are in the scope of this definition. The section Definitions, at the end of the document summarizes the list of terms and their meaning.
This document provides a roadmap identifying the current usage and potential of mobile technologies in Development and the current challenges and barriers and the potential directions to explore in the future. The focus of this work is on content, applications and services. While there are many initiatives looking at improving connectivity, bandwidth and infrastructure in Developing Countries, this roadmap explores how to use existing infrastructure to provide services that would contribute to social and economic development of rural and underprivileged populations. In this regard, the document targets mainly devices that are currently deployed (low-end phones with small screens). In this version of the document, mobile phones are considered exclusively as a platform to access services and content, and not a platform to author or deliver them. This version does not investigate specific application fields, but rather focuses on content, application and services in general. Read the Scope of the Document section for further details.
This document is organized into ten sections. After this introduction, the second section presents the motivation behind the work, the rationale for focusing on the mobile platform, and the gaps this document intends to fill. The third section introduces and describes the objectives. The fourth section details the scope of the document. The target audience is defined in the fifth section. The sixth and seventh sections are the core sections of the document, introducing the major challenges preventing a widespread usage of mobiles in development, and the technologies available today, with their major strengths and potential improvement to address the identified challenges. The last three sections provide a short conclusion of this work, a set of references that were useful in the development of this document, and the list of people who contributed to the work.
This work is part of the [6]EU-FP7 project Digital World Forum focusing on the use of ICT to leverage economic development in Africa and Latin America.
The emergence of new information and communication technologies (ICT), the Web and Internet in particular, in late 80s, has changed the World, offering a new paradigm in communication, exchange and commerce. ICTs are also a great opportunity for the Developing World. Providing basic social services (such as Health, Education, Business, Government, etc ) to rural communities and under-privileged populations is of major importance to improve people's lives, and to sustain development. Using ICTs would be the easiest and possibly only way to develop and deploy those services. It is therefore critical to work towards finding solutions by realizing the potential of this digital opportunity.
In this context, the recent explosion of mobile telephony in the Developing World is a great opportunity. During 2009, according to the GSMA and ITU, the total number of mobile phone subscriptions reached 4 billion, and 80% of the world population is currently covered by a GSM network (source [7]GSMA universal Access report, [8]ITU Press Release). These numbers illustrate the potential of the mobile platform to be the right solution to deploy services now, compared to other existing (e.g. fixed line) and emerging options which are still in development phase (e.g. low-cost laptops). Scientific micro-economic studies have provided clear measurable results. Recent Studies in [9]fishing villages in India, in [10]crop markets in Uganda, or [11]grain markets in Niger have demonstrated the impact of mobile phones and associated services on productivity and social development.
However, the potential is far greater than this number. Indeed, it is still quite difficult to develop and widely deploy reliable mobile content, services and applications targeted at and addressing specific communities' needs. Despite the proof of concept demonstrated by numerous success stories (see a [12]list of this stories) over the last few years, there is still today a limited number of services available in the world, a limited number of actors in the Development sector able to mainstream mobile technologies in their work, and a limited number of people in Developing Countries having access to development-oriented services on mobile. The role of the W3C MW4D IG and this document therefore is to assemble a global community of all stakeholders of the domain, identify the major obstacles preventing development, and thereby take valuable steps toward realizing the full potential of the mobile platform.
There is currently no global initiative involving all the stakeholders from the domain of mobile ICT for Development, and investigating how to realize the full potential benefit of the mobile platform. This document, and the community around it, is striving to build consensus on the most promising technologies capable of achieving global impact and realizing the promise of ICT for Development.
The MW4D roadmap has two main goals. The primary objective lies within the short term and is targeted at practitioners. The roadmap seeks to provide actors within the field of international development with up-to-date reference information concerning the functionality and availability of mobile solutions; it also seeks to provide information about the tools enabling these solutions and how to integrate them within mainstream work processes. The document seeks to inform practitioners about the potential challenges which can be encountered during the implementation of mobile projects. This information is intended to facilitate the selection of appropriate technologies, techniques and workarounds by development practitioners, thereby lowering the barriers to mobile technology use and adoption.
The secondary objective is targeted at actors involved in leveraging the impact of ICT for Development. Its focus lies within the medium term. The MW4D roadmap aims to inform various global actors of the current challenges and barriers that limit the potential impact of mobile technology in development. More specifically, the document considers the following:
In this section, we describe in detail the different topics that are considered in the document, and those that are either out of the scope, or considered for a future revision.
Content and Infrastructure
As mentioned earlier in the document, the field of ICT for Development has been attracting notable attention from international organizations in the last decade. So far, most of the effort has been and is still focused on the development of connectivity, infrastructure and bandwidth. The general role of this document and the MW4D IG group is to focus on how to take advantage of these infrastructures, and particularly the existing availability of mobile networks, to deliver human-centred life-critical services to people. In other words, the focus of this work is on content and deployment of numerous services.
Content and Infrastructure can be seen as different layers. The infrastructure offers different channels to the Content or application layer. In this document, we will not investigate the different technologies used in the infrastructure layer, but rather, we consider that the layer provides potentially three types of channel and an associated cost for each of them. The three types of channel are the following:
NB: in this document, the term channel of communication will be used instead of the more appropriate technical term[196]bearer services which might be less clear for non-technical readers, or non-specialists.
In the domain of mobile networks, GSM networks provide by default the voice and signalling channel, with data services offered following the launch of GPRS-enabled networks.
This document explores how to leverage these three channels to deliver content, applications and services to people. We consider in the document that we are working within the scope of mobile networks, i.e. ones where voice and signalling channels are available. However, in specific cases or under certain conditions, these channels are not available: only the data channel (e.g. Wifi or Wimax connected mobile phones) is available. In these cases, the voice channel can be simulated through voice-over-IP (VoIP) applications, and all recommendations and observations made in the document are still applicable, except the unavailability of signalling channel, and related technologies.
Mobile Device
The context of this document is to investigate how to take advantage of the huge installed base of mobile phones in Developing Countries to deliver development-oriented services to people. In that regard, the types of device considered are those widely available with small screen, limited interaction methods, limited input mechanism, and limited computing power.
Mobile and Development
This document attempts to evaluate the role of mobile phones in Development and their impact on livelihood. Mobiles are one of the tools that are available to the different actors of the Development sector, and the aim of this document is to understand the actions that would lower the barriers of integration of this tool and improve its impact in the work of the different actors. However, this document does not seek to help actors of the development sector to determine if, for a specific domain or a specific issue, for example, a mobile-based content or service is the most appropriate solution to select. Numerous studies (see e.g. [13]Mobile for Development Report by Plan) underline the importance of considering ICT in general as a tool and not as an objective to solve existing problems and issues.
Application Field
This document focuses on evaluating generic technologies that enable the delivery of content and applications on mobile phones. While [12]the existing projects and stories in different applications domains are very useful to capture the potential and challenges of each of these technologies, this version of the document will not consider specificities of each application domain (challenges of the domain, potential impact of mobile in the domain, importance of the domain in social and economic development, etc).
Mobile broadband and Smartphones
This document derives its content from studies of field experiences, and therefore reflects what is available today in targeted countries. Technologies and infrastructure considered in this document are already widely available, or will be so in the short-term. For instance, this document does not investigate the possible mid/long-term future when mobile broadband and smart phones will be widely available.
Accessibility
Accessibility of devices, services and content for people with disabilities is critical to ensure that the benefits of ICT and the Information Society are available to all. This topic has been a focus of an extensive domain of research and development since the early days of the Web, with the launch in 1997 of the [14]W3C Web Accessibility Initiative.
This roadmap does not aim to explore this domain in depth and/or identify new topics for exploration. However, because potential content authors' need to understand the work done in this area, the Challenges section has dedicated a chapter to this field, referencing both the relevant material developed by other groups, and the tools available.
Mobile as an authoring and delivery platform
There are two themes that are currently emerging in the field of mobile for development: mobile as an authoring platform and mobile as a delivery platform. Concerning the first theme, the potential of mobile phones as an ICT platform is based, as mentioned before, on the still growing but already extensive penetration of devices and networks all around the world.
However, today most mobile applications development takes place in a desktop PC environment, and therefore people who do not have access to PC are merely content recipients and can barely become producers or providers of services and information. This is clearly a problem, but some initiatives (see e.g. [15]kiwanja's mobility project) are starting to explore how to offer authoring and development environments on mobile phones, enabling those who have access to this platform to become service providers. Concerning the second theme, there are some experiments on peer-to-peer models where people can expose and share some of the content of their mobile to their friends, families and colleagues. Some of these experiments are very specific ([16]sharing music, [17]sharing photos) and some are more general, such as the development of a web server for mobile phones (see [18]Nokia's project). Such solutions are very new, and are potential options to provide connectivity or to lower the costs of offering information locally. Both domains are at the early stages of exploration, and while they are interesting concepts, the study of these two fields will be considered in the next revision of this roadmap, when they are more mature.
Technologies
A mobile phone can handle many different technologies and types of application. There are many different ways to group these different technologies. In this document, we identify three families based on the channel of communication they use:
Applications using the signalling channel of mobile networks. Mobile networks have a specific channel of communication, called signalling channel, which is used to monitor the network operation. The two major technologies relying on this channel are SMS ([3]Short Message Service and USSD ([2]Unstructured Supplementary Service Data).
In the Technologies section of this document, we describe in detail each of these families of technologies.
NB: This document is a technical roadmap that requires the reader to have domain knowledge and a technical background.
This document targets different actors of the ICT for Development domain at different levels. The following is a list of the major stakeholders and their potential interests in this roadmap.
This section of the roadmap presents the challenges identified by W3C MW4D IG that limit the impact of mobile technologies in the Development sector. This part of the document is split in two sub-sections: the first part explores the challenges of access, and the second part describes the challenges of service development and deployment.
This section describes the challenges users may experience when accessing specific content, services or applications. The challenges described below may or may not be relevant in the implementation of a specific project, but may need to be assessed or considered.
For each of the challenges, the document describes the issue, why it merits consideration, the different options - technical or otherwise - to solve or work around the issue and the research and development (R&D) actions that could facilitate its management.
Accessibility, in the context of broader Web access and in this document, in particular, covers the challenges of accessing and using devices, content and services on the Web for people with disabilities. Since the early days of the Web, extensive work has been conducted at the technical and policy levels to ensure that everyone, including those with disabilities can access all content of the Web. In that regard, when designing and implementing an application, it is critical to use the right techniques that would allow people using assistive technologies to access and interact with the service. While it is a very important issue in Developed Countries, it is even more critical in Developing Countries. For instance, 87% of the visually impaired people in the world live in Developing Countries (see [19]WHO Fact Sheet). Some countries are promoting or enforcing accessibility in their policies, e.g. [20]Read Manila Declaration on Accessible ICT.
The following section references the relevant work done by the [21]W3C Web Accessibility Initiative, and by the [22]W3C Mobile Web Initiative, and briefly introduces the ongoing work around availability of low-cost assistive technologies in Developing Countries.
Web Content Accessibility Guidelines
The [14]W3C Web Accessibility Initiative (WAI) develops a set of documents named Web Content Accessibility Guidelines. These documents explain how to make Web content accessible to people with disabilities. Web "content" generally refers to the information in a Web page or Web application, including text, images, forms, sounds, and other media.
From the [23]WCAG Overview page, there is a list of resources that can help a content or service developer to meet accessibility criteria.
Device Accessibility
The [14]W3C WAI and the [24]W3C Mobile Web Initiative have also jointly developed a set of documents that are considering accessibility in mobile browsing. Content and application developers will find relevant guidelines and best practices on the [25]Web Content Accessibility and Mobile Web Overview page to ensure that their content is accessible.
Assistive Technologies
The W3C WAI has identified the [26]key components required for the Web to be accessible to people with disabilities. While most of these components are not specific to a developed or developing country context, this resource merits further investigation. Indeed, Assistive Technologies (AT) consist of screen readers, alternative keyboards, switches, scanning software, etc and provide a human interface to the alternative text in various modalities. Access to AT and their availabilities and affordability in a Developing Countries context are important issues. These issues are well-known in the accessibility domain and a relatively large number of free AT are starting to become available. Organizations such as [27]Raising the Floor with their '[28]Solutions for Those with Extremely Limited Resources' group are also investigating this area and working toward making more AT both available and affordable. See also [29]Assistive Technologies Solutions who offer designs and plans, not specific to Web and ICT but with some dedicated sections on these topics.
[30]According to UNESCO, there are roughly one billion non-literate adults in the World, with 98% of them in Developing Countries. Many countries in sub-Saharan Africa, south-east Asia and Latin America have a low rate of literacy among adults, sometimes below 30 or 40 percent of the population (see the [31]UNDP Human Development Index and a [32]World map of illiteracy).
Illiteracy is clearly a profound barrier to access of written content and applications on the Web. This is also a barrier stopping underprivileged people benefiting from ICTs and accessing to development-oriented services. It is therefore essential for content or service developers to evaluate the importance of literacy among their targeted end-user population. In general, when a service is attempting to reach the public at large, this challenge could be pervasive. It could also be present when targeting specific categories of the population, particularly those in the low-income groups or with [30]women who make up two-thirds of all non-literates.
In the remaining part of this sub-section, the document introduces different methods of tackling this issue and identifies a number of potential actions towards making ICT applications usable by people with low-reading skills. NB: At the time of writing this document, there are no standardized, well-established techniques and guidelines available.
Also note that the aim of this section is to help content and service developers create solutions that are usable by people with low-reading skills and not to understand how ICT on mobiles could help improve the literacy rates.
Proximal Literacy
The first possible workaround in delivering content and services to people with low reading skills is an organizational one, consisting of intermediaries that are literates. It is often possible to find a literate person in a community who could serve as a relay to his or her community. This model is particularly relevant in the Village Phone model, originally developed by Grameen Phone in Bangladesh and now [33]developed further by Grameen Foundation. In this model, the village phone operator is migrating from a pure phone operator to an ICT service provider. See for instance the description of [34]Community Knowledge Worker.
Through such an organizational setup, the barriers of literacy, as well as languages and digital literacy as described later in this document, can be lowered to a large extent. However, it is not always possible to rely on such a concept. For instance, in cases where the service is targeting users away from their communities (such as those "on the road", or migrant workers).
Using Voice modality
When people have low reading skills, the use of voice might be an option. There are two major ways of using voice applications or audio content.
The first one is to develop a voice application, also known as IVR (Interactive Voice Response). This document offers a dedicated section on Voice Applications that presents the principle, solutions and the strengths and weaknesses of this approach of providing ICT services and Web access. Here, the major issues are the requirements on the content authors to provide, in most cases, two different applications if s/he wants to keep a traditional more complex/complete textual version.
The second option to provide audio output for a service is to use techniques and devices such as screen readers, which were originally developed to address accessibility issues, particularly blindness or visual impairment. There are indeed today software screen readers available on mobile phones, which are generating audio output for application on the phones, including SMS and Web browsers. The most well-known examples are [35]Talks and [36]Mobile Speak. While these solutions offer very good results, they are not truly applicable in the context of this document. Existing software screen readers are still very expensive, and they are not available on low-end phones. Moreover, they require a specific installation process which in turn creates another barrier. Finally, none of the current solutions enable user input, and therefore interaction with an application is limited. We may see in the near future free and open source solutions of this kind. However, they would only provide partial solutions for people with low-reading skills till interaction and input are possible.
Using graphical representation / Meaningful icons
One of the most promising technical solutions in this area is the recent development of meaningful icons and user interface design for illiterate users. This domain is an active area of research and a number of papers on this topic have been published. See for examples [37]Optimal Audio-Visual Representations for Illiterate Users of Computers by Microsoft Research India and [38]Developing Design Recommendations for Computer Interfaces Accessible to Illiterate Users by Matthew Paul Huenerfauth.
There are now commercial pilots such as the [39]Nokia's life tools suite, that are building on these results. Some approaches have also tested combined solutions using meaningful icons annotated with voice.
While this domain is still mostly at the research level, the results demonstrate the promise of providing content and applications to people with low-reading skills. However, the major issue here is the cost of capturing and designing the icons and the interface in a culturally relevant way. There are currently no techniques, guidelines or well-defined methodologies to help application developers to design such interfaces and icons.
Potential Future Directions
As presented above, there are some solutions to providing services to people with low-reading skills, through the use, combined or not, of the voice modality and meaningful icons. This research must now move into the mainstream domain and build a community of people who have experience in one or more of these solutions. This community could help define guidelines, best practices and methodologies necessary to build user interfaces that are usable by people with low-reading skills. There are two major directions to follow with regards to icon design and graphics and vocal annotation integration. Building a community, developing resources, sharing experiences, standardizing best practices and disseminating information are all essential steps toward realizing a significant improvement in this domain.
[30]According to UNESCO, there are roughly 1.25 billion people speaking lesser-known languages. While many developing countries, particularly in Africa and Latin America, use English, Spanish or French as one of the national official languages, many people (specifically the poorest part of the population) speak, read and write their own native language only. The availability of content and services in these local languages is critical to lowering the barriers to access ICT. Unfortunately, few of these lesser-known languages currently exist in the Information Society. In the following section, the document introduces the different workarounds that content authors can use today to provide services to people who speak, read and write "ICT-unsupported" languages. The last part of this section introduces potential actions to launch toward increasing the number of languages supported in the ICT world. Readers interested in understanding this issue can also refer to [40]a definition of Localization and Internationalization concepts and how they relate each other.
NB: The term "lesser-known languages", in the context of this document, refers to languages not necessarily lesser-spoken in the World, but which do not attract attention from to the majority of the developer communities active on the ICT domain.
Low-reading skills related workarounds
Although there is clearly a significant difference between people who have low-reading skills and people who are literate in a language that is not supported in ICT, the only option today for content and service developers to provide usable applications to people in the later category is to implement some of the workarounds described in section 6.1.2.
Using intermediaries speaking a supported language
See details in section 6.1.2. This option would be effective in places where it is easy to find people speaking supported languages. This is typically the case in countries having a Latin language as an official language. Most African countries have French, English or Portuguese as national languages; most of countries in Latin America also have Spanish or Portuguese as a national language. In these countries, it might be easy to find someone in a particular community who is literate in the national language supported in ICT. In Asia, the challenge might be more problematic.
Using Voice Modality
See details in section 6.1.2. The problem of supporting lesser-known languages is also a hurdle in the Voice applications domain. There is indeed weak support for many of these languages in existing Text-To-Speech engines, and Speech Recognition engines. See details in the Weaknesses of Voice Applications. However, it is always possible to develop Voice applications using audio files that are recorded in the targeted languages. Though this brings more complexity and less flexibility to the application development process, it is today the only option to provide services in all languages of the world.
Increasing the number of languages supported
The only way to lessen the impact of this challenge is to increase support for more languages in ICT.
For a specific language to be supported by a specific technology, there are two aspects to consider: the infrastructure (that allows a document to be localized in any language and dialect of the world) and the components required for a specific language to be supported by all the elements of the content production and consumption chain (authoring tools, client-side applications, input and output mechanisms, etc).
Concerning the infrastructure, this is not an issue in the voice application area, at least regarding delivery of content to the user, which is achieved through an audio stream. How the content is conveyed and parsed to the platform generating the audio stream might be an issue. In the case of VoiceXML, see [41]W3C Speech Interface Framework. For other types of voice applications, this depends on the platform used.
In general, the problem is the support of speech recognition (SR) and text-to-speech (TTS) engines. The availability of these key components in Voice application development is a critical factor to leverage the number of these applications. Unfortunately, there is neither an established method nor guidelines on how to implement support for a new language in SR and TTS, therefore limiting the development of such components to experts in the domain. Developing a step-by-step process, and standardized APIs (Application Programming Interface) for such tasks, would ease the development process. These processes would also offer support for more languages through a community process, and help create an initiative around multilingual free and open source SR and TTS that would make a significant step toward realizing the potential of Voice applications in Development.
With regards to SMS, there have been some initiatives to support non-Latin scripts, but in terms of infrastructure many network operators still do not support [42]Unicode that allows almost all languages to be represented in SMS. The lack of support for this standard by some network operators prevents all initiatives at the handset level to offer a technology that supports more languages. It is therefore essential to promote the use of Unicode by all network operators for SMS.
At the Web level, for HTML and XML languages, internationalization and localization have been a domain of extensive research and development since 1998 and the launch of the [43]W3C Internationalization Activity. Significant material --[44]specifications, techniques, quicktips, software and so on-- have been developed by this activity, and a global framework for allowing any language of the world to be represented on the Web has been established.
Though this framework exists, there are still only a few languages supported. There is a need to identify the different building blocks and steps required to support new languages (character sets, fonts or input methods for example) and to identify the most important languages to support in the near future. An initiative by UNESCO, called [45]Initiative B@bel examined these issues in 2003, and [46]some resources have been developed in this area. However, this work needs further development, and a new leading initiative in this scope is required.
There is also a need for a global open source initiative to support free fonts. While similar initiatives such as [47]Font Forge, [48]Metafont, or [49]Freefont already exist, further work focusing on languages that are critical to lower the barriers to access ICT is essential.
The term 'Computer Literacy' or 'Information Literacy' describes the ability - usually through past experience and training - for someone to search, find and use new content, applications and services without requiring the provider of this content to develop dedicated training for his/her service. This specific challenge does not directly affect delivery of services, but is essential for the ecosystem of mobile content and services which will need to be able to cope with a huge number of applications in the future.
This challenge predominantly concerns Web browsing, as other technologies such as SMS or Voice applications require in all cases a specific advertisement and awareness campaign to disseminate information about the service itself. The only potential workaround for these other technologies is through portals. This workaround is described later in this section.
Furthermore, with respect to Web browsing, the critical challenge is to find a relevant service/information among the billions of pages available. Using a multi-purpose generic web browser with a complicated interface, manipulating URLs, or searching the Web are the basic required skills. These skills rarely exist or are not natural in many underprivileged populations, or to first-time Web users in general. As of today, there is no real solution other than training people. In the following discussion, we examine several workaround solutions that reduce the complexity of this task and some new technologies that have the potential to provide a better, more scalable solution to this issue.
NB: In this sub-section, we don't treat the issue of availability and ease-of-access to the client application on the mobile device. This topic is investigated for each technology in the Technologies section.
Portals
Portals are a way to offer, through a single unified entry point, access to a suite of services and content coming from different sources. This concept appeared on the Web in the 1990s before the emergence of search engines. However, portals are not limited to Web browsing and are also possible in voice, potentially in SMS, and other technologies.
They are a very powerful way to bring new content and services to people, and to largely reduce the complexity for end-users who usually have to search, find and use new content. A portal might be particularly appropriate in a community structure, or in a model like Village Phone Operators, where one member of the community is computer literate and whose expertise benefits the entire community. This is similar to literate intermediaries described earlier in this document.
However, portals have also limitations. The principle of portals is that they are managed, in most cases, by hand, by the portal owner. The visibility of services is therefore decided by the manager of the portal.
While there is no other easy way for new Voice or SMS applications to be found automatically (except advertisement campaign), a portal is not always satisfactory for Web access and they may lead to walled gardens, as happened during the early days of WAP and mobile Internet access. The use of portals should be considered as an intermediary step. While providing an easier way for people without Web experience to discover the Web and useful services, there should also be a way for them to acquire skills on how to search, find and access content not on the portal. This goal can be realized through the integration of full web access in the portal, and can be achieved with the simple addition of links to search engines.
Mobile Widgets
Mobile widgets and application stores have been largely publicized thanks to the popularity of the Apple iPhone. The development of similar services by many companies such as Google for the [50]Android platform, Nokia with their [51]Ovi Store, or Qualcomm with their [52]Plaza service (see [53]a complete list of these distribution platforms) demonstrate the growing interest of this new kind of technology in the mobile sector. While they are considered today as a feature of very high-end phones, this new technology, by offering an information-appliance type interface, has the power to facilitate the access to development-oriented services on the Web. Coupled with work on meaningful icons, it has the potential to lower some of the barriers mentioned in this document (see also the section on monetization of Services). It is therefore essential to evaluate the potential of this technology in reducing the required expertise to access search, find and access new services. Stores can be considered as a new kind of portal that provides access to content for users, and a business model for content developers
There are four different dimensions to consider: Access to services, discovery and installation of new services, development and deployment of applications by the content provider, and requirements on the handset. While it is critical to assess the improvement of usability brought by mobile widgets, it is also essential to understand the whole ecosystem that could lead to the appearance of numerous services, and would allow people to develop, deploy, and access services and content easily. For instance, these stores present the risk as mentioned in the previous part of this section, to lead to a walled garden situation, where users of these commercial stores are not able to access all content on the Web.
At the time of writing, there is no initiative investigating the potential of this technology to improve access to the Web for computer-illiterate people. Creating a community around this theme, with actors of the mobile industry, actors of ICT for Development domain, Web specialists and researchers, investigating and identifying the key components of the ecosystem, setting-up some pilot projects and developing a roadmap would be useful actions that could make a significant step in this area.
When developing services targeted at the bottom of the pyramid, where potential users have a very low-income, the cost of accessing and using the service is critical. In this section, we are not addressing the issue of monetizing services for the content developer which is addressed later in the document, but introducing the key aspects to consider for making the service accessible by targeted end-user.
Affordability is a key barrier for using ICT, and the major part of the cost is related to the infrastructure. However, how to lower these access costs is not part of the investigation of this document. The pricing scheme is usually related to many factors such as the policy framework and taxation scheme in the local country or region, the absence of monopoly or fair competition, the number of competitors, or the way the costs of the physical infrastructure are shared or not. There are specific studies conducted in this area on how to provide low-cost access to wireless infrastructure. See e.g. [54]Low-access broadband access and infrastructure roadmap of EU-FP7 Digital World Forum project. There is also research related to the use of other types of infrastructure other than mobile networks, such as Bluetooth technology, or radio broadcast, but this is also out of the scope of this document which focuses on leveraging the number of services and valuable content for social and economic development through existing mobile networks.
While the absolute cost of accessing and using a particular service is an important aspect, the critical aspect is really the return on investment (RoI) for the user. While services, content and applications around topics such as entertainment might be successful for many reasons, in the context of this document (which focuses on social and economic development), the rationale for a particular service should be to improve, one way or another, the income or the quality of life of the targeted users. The increase of income could be direct (e.g. saving travel time and expenses) or indirect, through e.g. education and training that would help the user to find (better) job, through health or agriculture services that can help the user to work better to increase productivity, and so on. Evaluating carefully the potential impact that the targeted service or application could have on the income of the user is clearly a critical step of any project requirement phase.
The RoI depends on the cost of usage of the service. There are two dimensions critical for the user: the total cost of usage, and the predictability of this cost. The selection of a particular technology has an impact on these two dimensions. Each technology relies on a specific network layer. There are different types of network connectivity or channel: Data, Voice and signalling.
Data channel includes technologies such as GPRS, 3G and related technologies which allow the implementation of data transfer. These technologies are still charged based on the size of the data transferred (per kilobytes) by operators in many mobile markets. In terms of costs, looking at the price per character provided to the user, this is the cheapest technology by far, usually between 500 to 1000 times cheaper than SMS (See [55]African signal and [56]some other sites for a list of the different pricing schemes and the price of SMS in Africa). However, except in the still very rare case of flat rate plans, the predictability of the cost with such technologies is almost impossible to establish, and completely out of management by the user. The user has no way of knowing in advance how much actual data will be transferred, and therefore, how much it will cost, before the end of their session.
NB: It is important to note that Data service characteristics and costs described in this section are related to mobile networks, and mobile operator pricing schemes. There are ongoing experiments and initiatives looking to provide free or low-cost flat-rate data connectivity to people through technologies such as Wifi or Wimax. As mentioned in the 'Scope of the Document' section, it is not in the scope of this document to discuss the underlying infrastructure technologies, however if a content author is designing a service in such context, the costs of access for the user would be marginal. There are also other technologies such as Bluetooth that can be used as the infrastructure layer to provide connectivity at no-cost. While the use of such technologies has an impact in terms of costs, and affordability for users, this has limited impact on how to build the content or application to deliver to the final user, and therefore also out of the scope of this document. Finally, the price of mobile data services might also be influenced by regulatory authorities to promote and leverage access to ICT services.
Voice-based applications use the voice channel for communication. The cost of this channel is the highest as it is based, like with regular phone calls, on the length of the call. For comparison, the price of a SMS is usually equivalent to a ~10s conversation in an inter-network call, and ~30s in intra-network call, which is a very short time to provide information to the user. However, the cost is completely predictable by the user, who can stop the application at any time by hanging up. Some possible workarounds are the use of the call-back mechanism through a [57]missed call by the user, or the use of free phone numbers.
NB: It is important to note that the references used to evaluate the costs of voice applications are based on the pricing scheme currently offered by operators, at the time of writing of this document. However, this pricing scheme might be largely influenced by the regulatory authorities, which might decide to promote voice applications by enforcing low-cost, or flat-rate costs for accessing such applications. It is also important to note that flat-rate plans for voice calls (e.g. within the operator network, or during off-peak hours) are starting to appear in different regions of the World. See announcement of such plans in India: [58]free unlimited calls within the operator,and a [59]pay-per-call model where people pay for a call, independently of its length.
Signalling channel is the channel originally used for signal exchanges, not designed originally for service delivery at the user level, but rather for the network operation. This includes SMS, but also other technologies such as USSD.
In term of costs, as mentioned before, SMS are very expensive given the number of characters available. However, there is no cost for the receiver of the message (except for the USA) and forthe sender, the cost is completely predictable, except in the case of [60]premium services where the cost is higher than a normal person-to-person SMS.
Some service providers have implemented missed call procedure that triggers the delivery of SMS message or [61]the other way around (SMS triggering voice applications callback).
Some other technologies on this channel, such as USSD, don't yet have a billing system associated with them and are still free for the user in most countries. This will no doubt change in the future, as some operators have already implemented billing systems for USSD. See [62]Vodacom and [63]MTN pricing in South Africa.
Also note also that many USSD-based services are not free.
Finally, while this is not related directly to cost, it is important to note that the vast majority of subscriptions in Developing Countries are pre-paid plans ([64]95%in Africa). This has a major impact in terms of how content providers monetize services.
NB: This section has the aim of informing potential service providers on the costs the user will experience when accessing a service. In that regard, we are considering the social and economic development a service could bring in terms of measurable impact and the RoI in terms of quantitative value only. There is a broader view on the qualitative impact of mobile and mobile services on people and human development which is far harder to quantify. It is essential to consider this broader perspective as an element in the overall ecosystem.
As mentioned in the previous section, the key focus of this roadmap is on content and not on the underlying infrastructure. However, it is important to bear in mind the specific context available on the targeted regions of the World (Developing Countries) has an impact on the selection of the technology to implement a specific service.
In the Technologies section of this document, each technology studied has a specific section on its infrastructure requirements. In this section, we detail factors to consider, and outline the information which needs gathering in order to drive the selection of the most appropriate option.
There are two major aspects to consider: the availability of Data service and the type of connection mode available.
In terms of type of connectivity available, as soon as a GSM network is in the range of the user, voice and signalling services are available. It is not the case for data service. The wide availability of reliable data service is a major limiting factor today for most of advanced technologies such as Web browsing. As [65]underlined during the last workshop organized in the scope of MW4D IG, the problem is not really the size of the bandwidth, and the availability of real broadband access such as 3G networks, but the availability of data service, even low-bandwidth ones such as GPRS, that would enable new types of technologies and services. It is important to note that there is a general (and wrong) perception on the cost of data services compared to other technologies (see details in the previous section), and the complexity of setting up such services (for example, GPRS set up generally requires just a single SMS message to the operator to configure the user device).
In terms of connection mode, it is also critical to evaluate if the users of the service will be able to work in a connected mode or a disconnected one, and at what duration. Among all the technologies, only SMS services allow a true transparent disconnected mode. Voice applications require a connected mode, and, concerning technologies relying on data services, while it might be possible to find workarounds sometimes, many do not have an off-line mode.
Another critical dimension associated with the infrastructure is related to privacy and identity. It is important to note that there is a relationship between the type of technology used and the way identity is provided and confirmed to the service.
For SMS services, and other services using the signalling channel, the information about the [66]callerID is carried to the service provider, and there is no way for the user to prevent that. In some cases this might be an issue when e.g. reporting rights violations. In some other cases, the service relies on this feature, for example m-banking systems. This might also be an issue in a village phone operator model, where it is not possible for multiple people using the same SIM card to have different m-banking accounts.
For voice services and voice applications, the user can decide whether or not to provide the [66]callerID information, and the service can decide to use this information as an identifier or not. The application can also decide to use an application level authentication, e.g. a username or password.
For data services, it is almost impossible for the service to get the information about the [66]callerID, and the authentication has to take place at the application level.
It is critical for a service developer to understand this issue, and the conditions in which the developed service would be used (e.g. through a village phone operator model or not) to make the appropriate choice of technologies.
NB: It is important to note that Data service and Voice service characteristics and costs described in this section are related to mobile networks, and the mobile operator pricing scheme. There are experimentations ongoing to provide free or low-cost flat-rate data connectivity to people in certain regions of Africa, particularly South Africa, through technologies such as Wifi or Wimax. As mentioned in the 'Scope of the Document' section, it is not in the scope of this document to discuss the underlying infrastructure technologies, however if a content author is designing a service in such context, it is worth bearing in mind that the costs of access for the user would likely be marginal.
Handsets are clearly a critical element in the overall picture of the mobile service delivery chain. There are two aspects to consider in this area: the type of handset and the model of usage.
Type of handset
In terms of characteristics, it is essential for a content author to have a sense of the type of handset available in the pocket of the targeted end-user population. For voice applications and technologies using the signalling channel (SMS or USSD) are available on all phones. All other technologies relying on data service depend on the support by the handset of data service, and availability of software and APIs in the operating system of the phone. It is extremely difficult to have reliable statistics on the availability of specific features, such as support of some kind of data service (GPRS or above), or availability of a Java API or a type of Web browser in the installed base of mobiles in the World. However, there are some important facts to note:
Low-end phones are now offering minimal data service support and Web browsing capabilities. See e.g. the characteristics of a [67]below-$50 phone with internet capabilities.
Most of the new phones shipped in 2008 have browsing capabilities. A [68]mobile industry market analysis found out that among the 1.15 billion of mobile phones sold in 2008, 92% have basic browsing capabilities.
Related to the section 6.1.2 and 6.1.4 presented earlier, the [68]same market study established that 90% of the shipped phones have a color screen, and 71% have the ability to display pictures.
It is also important to note that in 2008 the average replacement cycle of a mobile phone at a global level was 14 months. This number does not reflect the situation in Developing Countries, where the cycle is far longer, often due to recycling, reparation and reuse. However, while it is also very hard to get any reliable information on this topic, the trend of support of data services, higher level APIs and browsing capabilities is clear. In order to accelerate this trend, and enable higher level technologies and higher level of services and applications, it is essential to promote the availability of minimal characteristics in all phones, particularly the cheapest ones. These minimal capabilities should at least include the support of a basic data service such as GPRS, and the support of Java mobile applications that enable a wide range of applications, including Web Browsers.
Usage Model
As mentioned previously in this document, one popular model to increase access to mobile services is the use of a shared model, like the original public phone model. This model, originally developed in Bangladesh by Grameen Phone, is now being replicated in many places of the World. The use of such model in the targeted end-user population is an essential point impacting the design of content and services, and the choices of technology.
As mentioned in sections 6.1.2, 6.1.3, and 6.1.4, this model might solve some of the challenges identified in the document. It might also sometimes be an issue, related to identification associated with a specific SIM card, or callerID, as mentioned in section 6.1.6, or related to privacy when one can access history and information coming from previous phone usage.
Finally, the use of a community phone as a bank of information might also be a possibility. Technologies using textual content might allow people to more easily share the information and associated costs between them, e.g. getting the news, or the weather forecast. Here again, it is critical to understand the appropriateness of the technology in that case. For instance, voice applications provide information to the user of the service only. SMS services provide information to the user of the service, and any other user of the handset who can read the SMS. Web technology offers some kind of caching capabilities that can enable shared usage, but that could be largely improved.
It is therefore critical for a content author to identify, during the requirements phase, if the targeted end-user population is structured around such a shared phone model, and if this is the case, what implications it may have on the service.
This section of the roadmap presents the challenges and issues identified by W3C MW4D IG that may be limiting the number of people or organization developing and deploying mobile applications, content and services that could contribute to social and economic development. While the first part of this chapter (section 6.1) was targeted at helping content authors in the design of their applications, this second part is more dedicated to an international or a national audience interested in engaging actions that would create an enabling environment for mobile-based applications.
This section is structured in seven parts investigating how to raise awareness, build capacity, provide enabling tools, use the right business model, deploy applications, monitor and assess impact, and improving scaling up from a small project to a more widely used service.
For a number of years, the Development community has witnessed the explosion mobile telephony first, and later the appearance of success stories that demonstrated that simple services on phones have the potential to help the social and economic development of some communities (see e.g. [9]the case of fishing village in Kerala, India). Most of those success stories are very simple services, like weather forecast, market information, appointment managements and so one, which should be easy to replicate. However, this is not really what appears to be happening now. While we observe big projects developing at country or regional level, targeting huge numbers of people (see e.g. [69]Tradenet/Esoko or [70]Voxiva), there is still a low-level activity at the grassroots level. One of the major reasons for the low uptake of mobile ICT by grassroots organizations or entrepreneurs is the lack of awareness in two dimensions: what is possible and what others are doing.
Knowing what's possible
One of the major issues today is the lack of awareness around the potential and openness of the mobile platform. For lots of people, mobile phones are a closed world, more or less like television, where the content is developed by the handset manufacturers and/or the network operators. Very few people are aware that it is not necessary to have a deal with a mobile operator, or even their permission, to develop and deploy an SMS, voice or mobile web service.
Local creativity and innovation can be stifled by this lack of awareness. Just demonstrating what is possible and how to create content and services are often enough to unlock this potential.
Knowing what others are doing/have done
Another critical aspect is to know what others are doing. For instance, the number of crowdsourced election monitoring projects in Africa is growing very quickly. One the first report was from [71]Indonesia in 2005. Since then many other similar initiatives have appeared around the World e.g. [72]in Nigeria in 2007, [73]in Sierra Leone the same year or in [74]Ghana in 2008. The success of the original project and the media/blog coverage brought attention from many NGOs interested in doing similar activities. Those NGOs realized the power of using ICT in these kinds of initiatives, and decided to replicate the process. In this case, like in many others in different sectors, seeing people and organizations tackling similar challenges or targeting the same goals and integrating mobile technologies creates replication among other organizations, and helps them to learn from these experiences, and re-apply them.
One key factor for an organization to investigate and integrate new mobile tools in their work is to understand the impact of those tools in similar environments. It is therefore essential to reference the different projects, stories, and cases on the use of Mobile technology in social-oriented service delivery. In that regards, one first step is to link the different projects, as done by MW4D IG in its [75]wiki of Stories. Early initiatives include[77]kiwanja.net mobile applications database and the more recent [76]Mobileactive.org mDirectory. These initiatives could be extended further to include a more in-depth analysis of each example: what are the tools used, what were the development costs, the business model, the impact, the learning... Section 6.2.7 investigates in more detail the different factors that can improve the replicability of projects and stories.
The same issue exists in the development of tools. Many projects are developing their own applications while tools already exist with similar features. Some open source initiatives are trying address this issue. See e.g. [78]Open Mobile Consortium, altough the re-inventing of wheels also exists among the open source communities.
Potential Actions to address the challenge
In order to address the challenge of raising awareness of the potential of mobile technologies, it is critical to organize dissemination events, such as hands-on workshops aimed at local NGOs and entrepreneurs. In order to reach a greater impact, it might be useful to use cooperation networks and networks of NGOs with presence in many countries as a vector of dissemination.
Developing a repository of use cases or completing/coordinating existing initiatives with in-depth analysis is also an important resource which could trigger attention in different communities or in specific sectors not using mobile technologies as a tool today.
It is also important to attract attention and raise awareness at a public authority level. At this level, very few people are aware of the potential of mobile as an ICT platform, and very few regulatory bodies are informed of existing challenges, and how policy and regulation can impact positively or negatively on the growth of mobile content and services. Section 6.3 presents briefly some of the factors and key aspects in this domain.
Knowing what's possible, what other people have done and how they did it is critical as mentioned in the previous section. However, moving from an observer position to an acting role, designing and developing a service, often requires minimal expertise of the different technologies. Building capacity on mobile technologies is therefore critical. Few initiatives exist today, the two major ones coming from students and researchers of the Massachusetts Institute of Technology (MIT).
[79]African Information Technology Initiative (AITI): This initiative focus on mobile programming for students with a computer science background. Courses are organized by volunteers during summer sessions.
[80]Entrepreneurial Programming and Research On Mobiles (EPROM): This is initiative is of broader scope, covering both programming sessions and courses for entrepreneurs.
While the success of these initiatives demonstrates the needs and interests for training and teaching on the mobile platform, it is critical that their scope and coverage is extended. There are at least two dimensions in which they could be scaled up.
At present these courses are taking place at the university level. It might be important to extend them to other audiences such as NGOs, non-student entrepreneurs, and the public sector. The requirements of each of the targeted crowds should be investigated (technical level...).
It is also worth considering more technologies. While EPROM is briefly covering SMS applications, and Mobile Web, it would be interesting to develop these topics further, particularly around tools available for content authors. It would also be interesting to cover voice technologies. The inclusion of specific modules on entrepreneurship and business models is also critical.
Finally, the current coverage of these initiatives is still limited (generally a few countries only). In order to have a more global impact, it would be interesting to try to enable a viral growth of such a training concept through:
The EPROM initiative has demonstrated most of this concept through e.g. [81]a public wiki with training material. It would be beneficial to scale up the concept along the dimensions mentioned above.
The third critical aspect to enable people and organizations to mainstream mobile technologies in their work is the availability of tools. Indeed, in order to see a real take-off of mobile content and services, it should be possible for the thousands of small NGOs and individual entrepreneurs to create and deploy those content and services. However, most of these small organizations don't have expertise and skills in programming or in computer science and telecommunication in general. For them to provide services, it is critical to have access to tools that are free and easy to use, and that would enable authoring, and perform delivery action without programming skills.
There are different levels of tools that can enable those targeted non-computer-specialists.
Platform level-tools
Platform-level tools are tools which enable the use of a particular technology in a completely free way. An example is e.g. a SMS gateway enabling people to create group of users, and keywords to react on. It enables the application of SMS without being tied to a particular task or a particular service. Having such tools for all major technologies is important. In Section 7 of this document, each technology investigated has a section on available tools. Among the numerous features, the most important ones are:
As mentioned before, the different 'tools' sub-sections of Section 7 on Technologies list and link some of the existing tools for each technology. However, a more exhaustive investigation, as well as a complete and formal analysis of the landscape, and the identification of the potential gaps, is required. It would be essential to identify the critical requirements and most important features needed in each category (such as compliance to standards), and investigate their support in the current list of tools.
Application/Task Specific tools
Platform-level tools are important because they enable all kinds of content and services without restriction. For static content, or easy tasks like simple form filling without data analysis, this is usually enough. However, in order to have advanced features, complex user interactions, or dynamic content, it is difficult, without programming skills, to develop applications. It is therefore essential to have higher-level tools that are enabling specific tasks, or specific applications. Some free and open source tools are starting to appear. One of the most active fields is data collection. Data collection and results analysis are very common tasks in many sectors, like e.g. health (patient records), agriculture (market information), or election monitoring (filling reports on specific events).
Another leading platform today is [82]Ushahidi, a platform for crowdsourced information. This platform enables the mashup of different reports in a geographical representation. It could be used for very different purposes such as election monitoring or tracking the evolution of diseases in a region.
These higher-level tools enable more advanced applications, and it would be interesting to identify what kind of other types of tools would enable more services. An example could be around exploiting the camera available of many phones. See e.g. [83]the case presented during the MW4D Workshop in 2009.
A critical aspect for these tools is their ability to use different channels or technologies (e.g. SMS, Voice, Web...) and to rely on any underlying infrastructure that could change from one project to another. It is also critical for them to use standardized interfaces so that they could be 'mashed' together easily for a specific purpose or goal.
Here again, a formal analysis of existing products and the global landscape would be critical to identify potential extensions and required future developments.
Developing and deploying services is not free. Out of the specific time to learn the technology, design the service or content, and author it, there are other costs for the content author in setting up the service and delivering it to end-users. To be sustainable, it is essential for the organization to at least cover these costs, and even generate a revenue stream in the case of entrepreneurs. In some cases, it is also critical to provide a completely free service to people (e.g. providing health information or alerts). In this section, we describe, in the first part, the different types of cost a service provider should consider. In the second part, we introduce some information on how to monetize services, and in the last part we present a number of ways to provide free services.
Costs for Service Providers
These costs can be split into two categories: hosting and delivery costs.
Hosting costs are the costs incurred by the setup of an appropriate infrastructure that enables potential users to access the service. It is directly linked to the type of technology selected. In some cases, as with web content, one can find free hosting services. In other cases as with SMS, all you need is at least one computer and one mobile subscription to run the service. In Section 7 of this document, for each technology, the hosting cost is described.
Delivery costs are the cost incurred by the delivery of services. In the case of data-connection, there is usually no delivery cost, because there are many free hosting services all over the Internet. In case of SMS, the costs are associated with the sending of SMS to users. In case of voice applications, it depends on the initiator of the call. If the service is initiating the call, the cost is on the service provider. If the user is calling the service, the cost is on the user. It is important to note that in the case of SMS and Voice, the delivery costs varies according to the mobile network used by the service and the mobile network used by the user (international call and SMS, as well as inter-network call and SMS are more expensive).
Identifying and evaluating the costs of hosting and delivery is critical in choosing the right business model.
Service Delivery Model
As mentioned above and in Section 6.1.5, it is critical during the design of a service to identify who should pay for the service. Some services are public services and should be covered by the provider of the service whereas some commercial services should be paid by the user. Some marketing strategies recommend to start with free services to advertise and demonstrate their usefulness, before making them commercial. The choice of technology has a direct impact on the implementation of one or other model. In the next section, we will discuss how to generate revenue from a service. In this section we review the different free delivery models.
Each category of technology has its own strengths and weaknesses. In terms on delivery of services, voice applications are often the most flexible options. Two different models are available:
It is also important to note that Voice-over-IP (VoIP) systems are free to use (but should be considered, in terms of business model, as a data-service application).
The case of applications working on the signalling channel (see section 7.2) is not homogeneous. Most technologies in this category don't have a billing system, and therefore are totally free for users. This is not the case of the most popular one, SMS.
For SMS applications, one way to provide a free service to users is through the broadcast of information. It is also possible to imagine that one can implement a kind of call-back mechanism for SMS too. However, the issue with both options is the challenge for the user who has to interact with the service. Sending back information to the service is not free. Another option may be reverse-billing by the service provider, but this option is not always made available or offered by operators.
For applications using data-services, there is no specific cost for the delivery of the service itself, but the connectivity, the bandwidth and the size of data transferred is usually charged to the users, and cannot be supported by the service provider, as this is independent of the service itself.
Because the characteristics described in this section are intrinsic to each technology, there is no real way to change this situation at a technical level. Most of the solutions are at the policy level and are out of the scope of this document.
As mentioned in Section 6.1.5, the success of a specific service depends largely on the ratio between costs for the user and added-value. At the same time, sustainability hinges on costs on the author side being at least covered (it often provides additional revenue, i.e. profit, in many cases). In the previous section, we investigated how to provide free services to people. In this section, we investigate how to monetize services.
NB: We are investigating the monetization of services from a technical point of view. It is out of the scope of this document to help content authors define the right pricing scheme for their services. For that, the service provider has to make a detailed analysis including summing-up all the costs he has to support (development, hosting, delivery, advertising, training, maintenance...), evaluating the potential increase of income or interest and costs on the user side, his purchasing power , and so on.
Monetizing services means selling the service to the user for a specific cost. It is possible to implement the management of the monetization of the service independently, for example through a monthly subscription not managed within the application itself. In this section, we investigate the option to manage the monetization within the service.
With mobile technology, there are two options for the monetization: at the application level, and at the network level.
Monetization at the network level
Here, the principle is that the costs of the service will be charged directly to the user account (prepaid or postpaid) transparently to the user. The service provider has a deal with the network operator, or with a company linked to multiple operators which allow him to get a percentage of what is charged to the user (revenue sharing). Here again this largely depends on the technology:
Voice Applications
It is possible for a voice application provider to buy a surtaxed number so that user calling it will pay more than the usual cost of the call, and a share of the money is given back to the service provider. This solution is not very flexible altough it is relatively easy to implement, as it requires deal with operators or an external company at least, but usually is relatively easy to setup. However, in most countries, the policy framework makes it mandatory to easy identify these surtaxed numbers, and users are losing the sense of cost predictability, and are often reluctant to use such numbers.
SMS Applications
We are only considering in this section SMS. Indeed, while in principle, they can support monetization of services, in practice, other type of technologies need access to the billing system of the operator, as no other interfaces are available. This limits the use of these types of technologies for monetization.
Concerning SMS, the situation is close to the voice case, with 'premium rate' SMS offering revenue sharing. The situation is usually harder to implement across multiple networks, and the issue around predictability is also present.
Data-service Applications
In terms of data-service applications, there is no way to setup such revenue sharing option as the application as no knowledge on the underlying infrastructure providing data services.
Monetization at the application level
The principle is that the monetization is managed at the application level. This is not something generally possible for SMS or voice applications. It is possible to implement external payments from mobile phones through m-banking, but this is not linked to the service directly.
The major advantage of managing monetization and payment at the application level is the independence vis-a-vis the network operators, and its applicability in all types of connectivity.
Concerning Web resources, there is no simple, easy and transparent way of implementing payments on an application. There are the classical ecommerce techniques (such as using intermediaries like Paypal, or credit card number), but they are not applicable in context of very small amount of money ([86]micro-payments or micro-commerce), where the cost of the transaction can be up to ten or hundred times more expensive than the amount of the payment. As underlined in the [87]MW4D Workshop in 2009 Executive Summary, there is need for developing infrastructure, standards and tools in this domain.
With other types of data applications, the situation is similar. The application stores model mentioned in Section 6.1.4 represents a good option for revenue sharing, and for content providers to generate revenue from their content. This is, however, only for the sale of the applications itself, and often not for any micro-payments incurred during the use of the service.
In conclusion, while some techniques and solutions exists for monetizing services with SMS and voice, there is no simple methods for peer-to-peer payments without an operator in the middle, and this is a limiting factor for monetizing services using these technologies.
On the Web side, the absence of micro-payment technologies is also an issue that needs to be investigated further.
The major objective of any service or content provider is to reach as many people as possible, and to develop the largest possible community of users. Therefore, the strategy for the deployment of a new service is crucial. There are three dimensions to consider in the deployment phases: the dissemination of the information about the new service, the trust the targeted end-user has in the service, and the required training necessary to use the application.
Discoverability
The first factor is linked to the technology itself and its ability to offer a way for user to search, find and use new services. This is called discoverability.
SMS and other signalling channel-based technologies do not offer the user any built-in way of searching and finding new content and services. Operators usually offer a portal or a description of some of the services, but this is an adhoc service and any service wishing to appear in the list have to deal with each network operator. It is also a challenge to know how to use a service, except through extra interaction cycles (such as the generic 'HELP' keyword). Neither is it possible to really implement transparently the notion of portals in SMS for applications hosted on different SMS hubs (see details in Section 7.2.2).
Voice applications have similar issues. There is no way to automatically 'know' the phone numbers to call to reach a specific service. However, the use of specific technologies like VoiceXML (see section 7.1) can partly overcome this issue through the design of portals gathering different applications coming from different sources.
Web resources, in terms of discoverability, are the most scalable, flexible and easy to use option. Search engines have demonstrated their ability to handle more than one trillions of resources. Portals are also a proven method of decreasing the complexity of search. See a more detailed investigation on this topic in Section 6.1.4.
Other data-service applications can, on some platforms, rely on application stores that offer easy to use discoverability features. However, the policy associated with some of the stores might be a barrier for some application developers. Otherwise, authors can simply put their applications on the Web for download, and benefit from more general Web discoverability.
In cases of a lack of discoverability mechanism, or in a population with low computer literacy, the only way to disseminate information and raise awareness is through more traditional channels such as radio, TV, advertisements, and newspapers.
Trust
The second critical point is about trust. This is not a technical issue at all, but it is an important concept for a service author to understand. Although people might be aware of an existing application or content, they might not want to use it because they don't trust it. This is particularly the case for applications where there is no immediate payback, or that might have a significant impact on people. An example may be in the teaching new agriculture techniques. In such a case, people would decide to use new techniques that might jeopardize their production for a year if, and only if, they strongly trust the source teaching them the techniques. Identifying in a particular structure or community how the chain of trust is organized is critical in finding the appropriate entry points. The availability and use of trusted intermediaries such as village phone operators is a perfect entry point. When not available, the task might be more difficult, and it would be important to identify use cases, success and failures, and establish best practices in terms of trust. Technically, it might be possible to build trusted intermediaries in the form of portals. Such a solution should be investigated further.
In order to achieve the maximum acceptance rate of a product or service, one could also use a co-design process to develop it i.e., to design and innovate with people and not just for them. Co-design differs from participatory design and user centric design as it involves all the relevant stakeholders (end-user handset manufacturers, operators, software makers, etc) (c.f. [88]Challenges and merits of co-design of mobile concepts by Jenny de Boer, Liliane Kuiper, MobileHCI 2008) as active participants throughout the entire process of designing. The co-design process allows to understand the structure of the local community in order to receive input from the different stakeholders and emulate peers learning (c.f. [89]Social Dynamics of Early Stage Co-Design in Developing Regions by Divya Ramachandran, Matthew Kam, Jane Chiu, John Canny, James L. Frankel,Proceedings of the SIGCHI conference on Human factors in computing system) . As the technology literacy in emerging regions is often unknown, the use of artifacts is recommended to assess it and evaluate the market expectation of the community. A co-design/co-creation approach could also be used to imagine, launch, and grow a sustainable business in emerging regions. In that case, the co-design process will not only produce a product or service, but also a business model and a strategy that creates long-term community value and corporate growth (c.f. [90]BoP Protocol (2nd Edition): Towards Next-Generation BOP Strategy by Erik Simanis & Stuart Hart, et al.).
Training
The last point in this section is around training. People might know about a service and they might trust it, but for them to use it, they have to be trained. This is an important step in the deployment phase. The first step into the application depends of the technology itself. SMS is usually at the user's initiative: you have to know more or less the type of command you can send to the application. In that case, the training is important, depending on the number and complexity of actions.
With other technologies - voice, Web or other type of data-service applications- the initiative is on the service side: actionable content is presented to the user, either visually or graphically. However, there is today a lack of widely adopted guidelines for designing easy-to-use natural visual and vocal user interfaces. In the graphical user interface design, though a growing community is working on participatory design within the context of developing countries, defined methodologies, guidelines and best practices are yet to come. This direction has to be explored further. In the voice interface, there are no established guidelines and best practices. This has to be further investigated too.
Monitoring and assessment are critical activities in all projects, particularly in ICT. Most of funders and donors require project impact assessments. It is not in the scope of this document to discuss the best ways of assessing projects, identifying critical factors to measure, and best practices to measure them. There is extensive literature on these topics. See for example a review of this literature, [91]Compendium on Impact Assessment of ICT-for-Development Projects. However, we should note the importance of capturing and integrating user feedback about the content and service developed, and to monitor the device and network performance. Those factors are critical to understand the key barriers or improvements that could be integrated.
Scalability and Replicability are the two key concepts to achieve a global impact. When a specific service contribute to socio-economic development in a small community somewhere deep in a specific country, public authorities or development agencies are usually willing to scale such a system to extend the coverage. Scaling-up a service has usually two objectives:
The first and most traditional way of scaling up is just by extending the system (vertical growth): dedicating more computing power and more resources so that the service can handle more users, and cover more use cases. As underlined in the [87]MW4D Workshop in 2009 Executive Summary, there are a number of issues with such approach:
The other option for scaling-up a service is through replication (organic or horizontal growth). The principle is to keep a service simple, and only replicate it at other locations to extend the coverage. The best example of such a scalable model is the growth of the Web in past 20 years, moving from a single user to 1.5 billion userstoday. The Web, i.e. billions and billions of resources, is a completely decentralized system, with simple web servers handling small groups of users and resources. Below is an attempt to identify the key features that explain such successful organic growth, ones that are critical to create highly replicable solutions:
The concept of organic growth is essential for a real take-off of the number of mobile services and content. These key dimensions mentioned above can be seen as a summary of the different sections in this chapter that identify the different actions that are needed in different domains (awareness, expertise, tools, business model and deployment) to reach a point where all the conditions are created for numerous people to become contributors of services.
Telecommunications policy and regulations are major horizontal issues that cut across all the players involved in implementing MW4D projects. Content providers are not an exception. Telecommunications policy and regulations may influence MW4D projects in favourable or adversarial manners. All the various stake-holders in MW4D projects need to work in line with the requirements of the national telecommunications authorities within the country where the project is implemented.
The scope of regulation impact in project delivery is wide-ranging. For mobile phones, the following items are often under the control of the national telecommunications authorities or the incumbent telecommunications operators:
The telecommunications services and infrastructure are improving in developing countries, where the government takes the ICT sector as a growth focus, and where policy-makers favour market liberalization. It has been reported that the penetration rates of mobile phones has risen significantly in countries that introduced competition in the mobile telecommunications sector (Source: [92]The ICT Development Index, ITU, 2009).
The expensive cost of mobile phone service and the penetration gap between urban and rural areas are remaining challenges in a number of developing countries. For example, in a number of countries in Sub-Saharan Africa, the cost of mobile phone services are 20 to 60 per cent of Gross National Income (GNI) per capita. These are unaffordable levels. Policy-makers and project planners should work to keep end-user charges at affordable levels. When such services serve as public good and contribute towards human or econolic development, public contribution towards their running costs should be sought.
Project planners are advised to study as early as possible local practice of telecommunications regulators and operators in the areas where they plan to roll out socially-oriented mobile projects. In some cases, law enforcement may be left to the discretion of one person. Should they have the opportunity, project planners and implementors are advised to maintain good working relationships with local telecommunications regulators and operators.
This section of the roadmap focuses on the technologies used to build and deliver applications. As mentioned in the 'Scope of the document' section, this roadmap explores the three families of technologies depending of the type of network infrastructure they are relying on: voice applications, applications using the signalling channel of mobile networks and applications using data services.
This section is about voice applications. In the first part, we introduce the basics of this technology, and discuss the general strengths and issues associated with this type of applications. In the second part, we present the different options and technological solutions to develop such applications.
Overview
Voice applications are based on the use of the traditional voice channel. End-users place a traditional phone call to a specific phone number and reach a voice platform through which the service is accessed. From there, navigation through the application is done either by voice input (the user speaks to the application) or by pressing the phone keypads.
Voice Applications have different components:
[94]Speech Recognition Engine (SR): SR is the counterpart of TTS: it translates audio files into text. It is always possible to design a voice application without SR. In that case the only possible interaction with the user is done through the phone keypad. The presence of an SR allows a user to 'speak' to the application. Like TTS, a specific SR understands only a set of languages, and usually requires a [95]grammar to be provided by the application developer to increase the quality of the voice recognition process.
Without these extension modules, a voice application is just a management of multiple audio files that are served to the end-user according to a specific algorithm or flow chart.
Costs for service providers and end-users
As presented in Sections 6.1.5 and 6.2.4, there are different costs associated with development, deployment and access to voice applications: access price for the user, running costs for the delivery of the service, and infrastructure and hosting costs for setting up the service. We don't include here the costs of development of the service itself, but later in this section, we consider the level of expertise required, and the general availability of this expertise.
In term of the price of access to the user, it is the same as the price of a phone call. The basic pricing models are:
In terms of delivery cost for the service provider, there is not much costs associated with the delivery of the service itself, except in the case of free phone numbers and call-back services.
In terms of infrastructure and hosting costs, in order to deliver a voice service, the content provider has to rely on an infrastructure which is connected to the telephony system. If willing, service providers can deliver the service through VoIP or through the use of external VoiceXML content on the Internet (see below).
The cost of required infrastructure on the telephony side is a key aspect. While the price of software is not an issue with the availaibility of numerous free and open source solutions (see the tools section later in this section), the physical part that is handling the phone calls from users is relatively expensive. One major issue that increase the cost is the ability for the hardware to handle multiple concurrent calls. Indeed, the hardware managing few phone lines (1 to 8) is relatively inexpensive, but hardware managing higher numbers is far more expensive. Moreover the cost of the phone lines themselves is significant, and each line will be busy during the whole duration of the interaction with the user. That means that users will get a busy signal when the capacity of lines is reached. Offering appropriate capacities for voice services is a major issue in terms of costs, particularly when the service is provided by individuals or small organizations.
Strengths of Voice applications
Voice applications present a set of advantages that have attracted attention in the Development community. Among the major features, the following aspects are critical:
Weaknesses of Voice Applications
Voice applications have weaknesses and specific challenges for both the users and the content developers.
For content developers, one of the major challenges is centered around cost:
Cost of the additional modules such as TTS and SR. There are very few free and open source initiatives in that area. The best examples are [96]Festival for TTS, and [97]sphinx for SR which support only few functionalities.
The second set of challenges is related to the required expertise. Authoring voice application is not an easy task. In most case (see the proprietary PBX-based paragraph later in this section), the development requires advanced programming skills which limits the access to computer scientist and programmers. Moreover, the usability of Voice applications is another big challenge. Although it can be difficult for those without experience with voice application development to grasp, the lack of output in the form of written content is a significant issue. There are no widely available usability guidelines for voice applications. While [98]the needs for such guidelines have been recognized for a long time, there are still only very brief help guides (see [99]an example of such guidelines). However, it is important to note that new voice development frameworks are now available to ease the tasks of developers, and even enable people to provide content, and develop their own application by voice, through a phone call. Examples of such framework:
Such initiatives are paving the road to lower the barriers of developing and providing VoiceXML services and content.
Concerning the user issues, the first challenge is discoverability. It is impossible for someone to know what the available services that might be useful are. One of the major strengths of VoiceXML compared to other voice technologies is its integration with the Web and its independence vis-a-vis the infrastructure. It is therefore possible to search the Web and find existing VoiceXML services and applications, and build portals to offer access to these services. It is even possible to link different portals together. There are examples of voice applications directories such as [103]GOOG-4-1-1, which are referencing applications and their association with phone numbers, but this requires the author of the application to advertise to all directories.
The second important issue is around the nature of the information provided through voice applications. Its lifetime tends to be short and there is no built-in way for the user to save or keep the information or the audio stream for sharing with others, or for re-listening or re-using the information. Each time the information is needed, the cost of accessing the service has to be paid again, and the handset has to be within the range of a network (no off-line/disconnected mode capabilities).
There are initiatives to solve this issue. For example, some services are now investigating the use of voice mailbox service available with all subscriptions to provide information for multiple usages. There are also some devices enabling the recording of the audio stream. An example is the [104]Literacy Bridge.
NB: This paragraph concerns the reuse by the end-user of information provided by a voice service. It does not cover the case of applications that are enriched through interaction with end-users. For instance, some services have a body of information (like e.g. a Question and Answer service) available, and if the end-user needs an answer not available, the answer is delayed, provided later, and the service is completed for future usage, reducing the time needed to access the information. This is a feature at the application level, independent of the technology used to deliver the information to people.
Examples
Below are three examples using this technology:
Type of technologies and development environments
There are different options available to build Voice applications. As mentioned in the previous paragraph, the voice services rely on an underlying infrastructure handling the calls and the phone lines. This infrastructure as a whole is called [107]PBX or PABX (Private Automatic Branch Exchange). These PABX could be an individual piece of hardware or just software on a desktop machine with appropriate extension card receiving the phone lines (mobile or fixed).
Almost all PABX offer some capabilities (APIs, tools, etc.) for developing voice applications. However, those capabilities are in various stages of development, they have different levels of accessibility by non-technical specialists and exhibit various levels of standardization. Below, we present briefly the most well-known non-standardized option, and then focus on VoiceXML, the standardized approach.
Proprietary PBX-based solutions
As mentioned above, almost every PABX provider has its own feature list, and set of APIs for development of voice applications. The major issue with such solution is the proprietary aspect of the solution. In general, the application has to be specifically designed and developed for the specific PABX, and is generally not easily portable on to other models. It is particularly difficult to scale up from a few-lines hardware to a larger infrastructure. Due to this proprietary aspect, it is difficult for generic tools to offer a voice channel and maintains support on all PABX.
Having said that, it is important to note that one platform is attracting particular attention from NGOs and organization working in the development sector. This is the free and open-source platform [108]Asterisk. It is the most widely available and popular software PABX solution and has a strong and very active community behind it. It accepts all the majors commercial, or free TTS and SR engines, and various complementary modules are freely available.
However, it is important to note that voice applications developed on Asterisk work only on this platform, and it requires extensive programming skills.
Standardized infrastructure-independent solution: VoiceXML
Since 1990, W3C is leading a global industry initiative, called [109]Voice Browser Activity, in charge of developing a standardized Speech Interface Framework around [110]VoiceXML. This initiative, gathering all the major PABX manufacturers and voice application specialists, has as its major objective to provide a way for application developers to use a standardized layer for voice applications, independently of the underlying PABX, and to integrate voice applications on the Web.
The aim of VoiceXML is to use a standard way for voice to access Web content, in the same way HTML is a standard for visual content.
The diagram below summarizes the functionalities and commonalities between VoiceXML and HTML.
Like any Voice application engine, VoiceXML supports the use of TTS, SR, and plain audio files. The application is completely independent of the underlying PABX infrastructure. All major PABX providers, including Asterisk, support VoiceXML directly or through third party extension modules.
The use of VoiceXML for voice applications presents a number of advantages:
VoiceXML is a specific language, but the [41]W3C Speech Interface Framework is a complete family of languages that covers all aspects of voice applications, including [95]Speech Recognition Grammar Specification, or [111]Speech Synthesis Markup Language. See the complete list of [112]Voice technology developed by W3C.
Tools
There are many free and open source tools available for voice applications. Below is a list of some of these tools. The MW4D IG is [113]referencing a preliminary list of these tools on its wiki. This list does not aim to be exhaustive, and there is a need for a more formal analysis of the tools landscape in the VoiceXML area, and their compliance with the different standards released by W3C.
It is important to note that while it is possible to build a low-cost infrastructure for delivering voice and VoiceXML applications using a combination of cheap hardware, Asterisk, and free Voice Browser modules, advanced expertise is required, particularly to install and configure Asterisk and the underlying operating system.
Future directions
In this paragraph, we detail potential activities that would increase the impact of these types of applications, and the number of usable and useful services available.
The first important point is to build a community around this theme. As underlined in [87]the last MW4D Workshop in April 2009 and evidenced by the examples mentioned in [12]MW4D wiki: Stories, more people and organizations are now field-testing this technology. It is essential to create a forum to exchange results and to identify key factors of success. It is also essential to disseminate information about available tools and solutions to ease implementation of low-cost voice applications.
The second important point is to raise awareness and promote the use of the standardized, web-integrated option, VoiceXML and its related set of languages. VoiceXML has been originally developed by the industry, for a business purpose. Meanwhile, the development community has been focusing almost exclusively on the use of the open source solution Asterisk. While Asterisk is great software PABX tool, it should not be the platform for application development. There are free modules on top of Asterisk (see the [113]MW4D Wiki on voice tools) that enable VoiceXML applications. Unfortunately, the lack of awareness on the potential of VoiceXML and the availability of tools limits its adoption in the development community. This task should include training courses, and the future development of degree/modules at Universities.
Thirdly, as noted in the tools section, there are some tools available, but a formal analysis on the tools landscape could help content authors. A study of the tools' standard compliance, how they work together (TTS, SR, voice browser, authoring tools, etc.) and what gaps there are in their availability is needed.
The fourth aspect focuses on language. As mentioned in Section 6.1.3, there are only few languages supported by TTS and SR engines. Those modules are critical for easing the task of content authors, and therefore it is necessary to establish easy-to-implement process for supporting new languages in these modules. [118]Some work has already started, but a more global initiative on this topic is required.
The fifth aspect mentioned earlier is the lack of usability guidelines. This is not specifically related to work in Developing Countries, but usability guidelines are critical to enable more potential authors to develop usable voice applications.
Finally, one of the key barriers today is still the infrastructure. It is almost impossible for individual organizations to provide an appropriate infrastructure. The availability of such infrastructure, or global hosting service, is critical for the real take-off of this technology. This is relatively easy to implement at an operator level, and there are already such hosting services available on the Web, even for free (see [119]Tellme Studio), but these services are for now almost exclusively providing phone numbers in the USA. Implementing something similar to application stores at an operator or country level might be a way to have an affordable scalable hosting solution. Another approach to addressing the same issue might be toward packaging some tools together in an easy-to-use, easy-to-setup low-cost solution for setting up a minimal infrastructure for the deployment of voice applications.
This section is about technologies using the signalling channel of the mobile network. Mobile networks have a dedicated channel, called signalling channel, used to monitor network operations, and monitor activities on the other channels (voice and data). Since the early days of GSM, the network standards have included the implementation of two protocols or technologies to exchange information using this signalling channel, [1]Short Message Service (SMS), and [2]Unstructured Supplementary Service Data (USSD). In the last part of this section, we also briefly explore a more recent technology called [120]Cell Broadcast.
Before discussing the specificities of each technology, we introduce the characteristics specific to the signalling channel. In subsections 7.2.2, 7.2.3 and 7.2.4 respectively, we investigate SMS technology, USSD and Cell Broadcast.
The use of this specific channel as the transport layer for applications has some constraints and specificities. This type of channels is part of the GSM specifications and a characteristic of mobile networks only. Therefore, it is impossible to develop applications based on this infrastructure in the absence of a mobile network (e.g. using other types of connectivity other than mobile networks such as Bluetooth, Wifi or Wimax).
In terms of internationalization, there are still many network operators which do not support appropriate [121]characters encoding on the signalling channel which would allow all characters of the world to be represented. The GSM specification makes mandatory the support of GSM 7-bit alphabet, but optional the support of [122]UTF-8 and [123]UTF-16 which does allow encoding of all characters. See e.g. [124]details on message size and structure for SMS.
In terms of availability, because SMS and USSD are part of the GSM specifications, they are supported on all mobile networks and all handsets.
In terms of capabilities, the signalling channel is supporting text only. There is no way to support any other type of data than text.
In this section, we investigate the use of SMS for delivering content and services to people. In the first part, we introduce the basic idea, and address general strengths and issues associated with these types of applications. In the second part we present the different options and technological solutions to develop such applications.
NB: It is important to note that in this section the term SMS application covers the case of applications using SMS as the transport protocol, and as SMS client and functionalities (reception and emission) on the handset. There are nowadays applications (see e.g. [39]Nokia life tools or [125]frontlineSMS form) using SMS as the transport/network protocol only, exclusively or in the absence/unavailability of other network technologies. It is out of the scope of this document to discuss and compare the relative strengths and weaknesses of each network technology used at the network layer. Those types of applications, by requiring download, installation or use of a specific application on the handset, are studied in the section 7.3.3, while the constraints described in section 7.2.1 still apply. In any case, it is important to mention that, given the current pricing scheme adopted by most operators, SMS is the most expensive option, in terms of price per character, to deliver content to users.
Overview
Originally, SMS was designed to be a person-to-person text messaging system, but then evolved to be used as a way to deliver information to people. There are two types of applications, based on the way the information is provided to the user:
Broadcasting of information (push method): the information is provided to users when the service decides it, or when the information is available. The user can usually just subscribe or unsubscribe from the service. Typical services are alerts (e.g. [126]Tsunami alerts system in Thailand), or weather forecast.
User-driven services (pull method): the user sends an SMS to the phone number associated with a specific SMS service with one or more keywords and associated content in the body of the message. The SMS system receives the SMS, parses it, and according to the keyword and information provided, builds an answer and sends it back to the user, in one or more messages. Even if SMS is a stateless protocol, it is possible to have a service implementing multiple cycles and interactions with the user, through e.g. identification of the [66]callerID.
All the SMS platforms, also known as [127]SMS Hubs, offer the possibility to manage different keywords, different actions based on keywords and callerID, and different groups of users.
Costs
As presented in sections 6.1.5 and 6.2.4, there are different costs associated with development, deployment and access to SMS applications: access price for the user, delivery cost for delivering the service, and infrastructure and hosting costs for setting up the service.
In term of access price for the user, the reception of SMS is free (except in the US). All the information received from the system is therefore free. The user pays only the messages s/he is sending to the service. It is important to note that in some cases the reception of content is not free, or the sending of a SMS to a number is over-charged. This is known as [60]premium-rated SMS services.
In terms of delivery cost, in all cases, the service providers have to pay SMS sent to the users. The cost of each SMS depends on the service and user origin networks (inter-operator SMS are more expensive than intra-operator SMS). In order to reduce these costs, almost all SMS hubs support the management of multiple modems, and multiple subscriptions, that allow the service to select the least expensive options. There are also some services available like [128]clickatell or [129]bulkSMS which are providing SMS sending in various networks at reduced costs, but require an Internet connection. Despite these potential ways of reducing this part of the service operation, this cost is still a major barrier to deploying SMS services.
In terms of infrastructure and hosting costs, in order to deliver an SMS service, the content provider has to have an SMS hub which is the place where the service is run and delivered to the users. There are few software SMS hubs, that require only a PC and a GSM modem (that can be just a mobile phone connected to the PC). See e.g. [130]How to build a SMS Hub. This piece of infrastructure has to run 24 hours day (or at least during the supposed working hours of the service).
Strengths of SMS
SMS applications present a set of characteristics which make them the most-used technology in the development sector. Among the major features, the following aspects are critical:
Weaknesses of SMS
SMS applications have also some weaknesses and specific challenges for both the user and the content developer.
Concerning content developer challenges, as mentioned earlier, one of the major issue is around cost:
The second challenge for developers is the lack of standardized interfaces for SMS Hub. While the low-level APIs to manage SMS and the GSM modem are standardized, the application level is not, which make almost impossible the transfer of one application from one SMS hub to another. It is also important to mention that there is no initiative currently exploring the integration of SMS on the Web in a similar way as voiceXML is used in the integration of voice applications of the Web. Past initiatives, such as[131]SMS Forum, used to explore some of these issues, but have stopped their activities. The launch of a new initiative in that area might be useful, but would also be questionable in terms of long-term impact, and the foreseen lifetime of SMS technology as an application platform.
The third challenge for developer is the limitation of the technology. Not only each message is limited at best to 160 characters, but complex multi-cycle interactions with the user are complex to implement, and not offered by most popular SMS Hubs (and would also be costly for both the user and the service provider). For query-based services (weather forecast, price of goods, etc.) these limitations would not be a huge issue, but for e.g. filling a set of successive forms, this would be an issue.
Concerning the user issues, the first challenge is discoverability. It is impossible for someone to know what the available services that might be useful are, and even if the number is known, what the keywords to put in the message are. This is a problem particularly if the number of SMS services is growing. There is no way, like e.g. for voice application to record the phone numbers with the keywords in the handset contact list.
The second challenge is related to the fact that only textual information is available. This is a major issue when targeting population with low reading skills. That's one of the major problems mentioned by SMS service providers, who are often moving from SMS to Voice applications (or adding a voice access to their service).
Finally, as mentioned in section 7.2.1, lots of languages are not supported on SMS, and therefore, it is impossible to deliver SMS services in local languages in many regions of the world, not because of the limited capabilities of the handset or unavailability of fonts, but because of the inability of the network to support the right encoding. It is important to note also that the implementation of the right encoding has an impact of the size of the SMS message available for user-data. For instance a 8bit-encoding, required to support e.g. accentuated Latin characters, allows 140 characters, and a 16bit-encoding needed for Arabic, Chinese, Korean, Japanese or Cyrillic alphabet allows 70 characters only.
Example