Re: Tools methodology

In order to fuel the discussion we will have later today, i'm writing 
down some of my thoughts/thinking/2cts on this topic.

-first, as the discussion on the mailing-list demonstrated, it is 
essential to define in details the objectives of this work. For me, the 
goals are to come with a methodology on how to sort and analysis tools 
so that it is easy for people/organization to identify what might fit 
their needs.
- we also have to scope correctly the work. Mobile tools can be a very 
broad topic. For instance, a mobile web browser like e.g. could be 
considered as a mobile tool to access the Web. But for me, i had the 
impression when we discussed this work item that we were more thinking 
about mobile "authoring" tools, i.e. tools that would enable the 
delivery of content and services to people. I believe it is worth having 
a discussion on this.

-then in terms of the type of information to be captured that helps the 
selection: based on my own experience, i usually needs to know
*type of phones required: working on all phones, or on feature phones 
(TBD in details, but for me java-enabled phones), or smartphone
*type of transport layer used: communication channel, SMS, USSD, data 
connection
*type of connection required: working offline or need to be connected 
during usage
*type of requirements on the user side: working on existing phone client 
application (e.g sms client, mms client, phone client), needs a general 
client that can be present or downloaded (typically a web browser), or 
need a tool-specifc download (like a dedicated java application)
-type of services provided: infrastructure type of tools (like a sms 
hub, or a voice platform), task specific (market prices type of tools), 
authoring tools (CMS, html auhtoring tools, etc.)
-operator (in)dependence: needs auhtorization and deal with operators or 
just simcards needed, work accross multiple operators, etc.
-language support and requirements

When it is about mobile authoring tools, it is obviously critical to 
separate the requirements on the user of the tools (i.e. content 
providers) and the requirements on the end-user (i.e users of the 
services provided through the tool).
about requirements on the content provider:
-technical level: does it requires programming skills, or is it usable 
by anybody without technical background, etc.
-infrastructure requirement: what does the content provider needs to 
have/provide: connection to the internet needed ?,
needs of computer running 24h/day ?, free hosting services available ?

about requirements on the final user
-type of final users: public at large or specific actors (e.g community 
health worker)
-textual literacy requirements
-push or pull type of information provision: information on user demand 
or broadcast

Obviously also, examples of usage (i.e. projects and stories behind the 
tool) are important


As a mentionned in a previous email, it might interesting to investigate 
what existing directories of tools are doing.
For now, we have been pointed to the tools section of mobileactive 
mdirectory (http://bit.ly/cqDD4p ), and we have a tools section in the 
MW4D wiki (http://www.w3.org/2008/MW4D/wiki/Tools ).
It might be good to explore further and see if we can find other 
initiatives around mobile tools, general ones or domain specific ones 
(mhealth, agriculture, etc).

Steph
Le 29/07/2010 15:16, Stephanie Rieger a écrit :
> Hello,
>
> I've volunteered to begin thinking about the Wiki's tools section and
> how best to develop a criteria to assess the suitability of each tool.
> For reference, here is what is currently posted on the Wiki in regards
> to the goals of the overall activity.
>
> "It is critical to develop a real landscape analysis, investigating the
> exact domain of applicability of the different tools, how they relate
> one to another, what is their target audience, what are their
> requirements for usage, etc. As part of these investigations, the
> growing importance of social networks such as twitter or facebook in
> developing countries and their potential roles in social development
> will be studied. This document will define a methodology to review
> mobile tools available for the different technologies, develop a
> landscape analysis based on the definition of taxonomy or matrix of
> factors to consider to select a tool. The document will also identify
> gaps, in software, features or standardization, that prevent more people
> from deploying content and services."
> [http://www.w3.org/2008/MW4D/wiki/Mw4d_tools]
>
> Stephane has suggested I post this to the group for comments. We also
> plan to discuss this further on Monday during the meeting. The list of
> assessment criteria below is preliminary...just to get the conversation
> started.
>
> Category - SMS, MMS, mobile web, voice, service etc.
>
> Cost to the organisation - One-off cost, subscription, cost of
> associated tools or components etc.
> License - Is the tool (or aspects of it) open source? Are there license
> restrictions?
> Roadmap - Are new features planned? Is the tool relatively future-proof
> from a technology point of view?
> User base - Is the tool proven? How many existing users/deployments? Are
> there case studies available?
>
> Ramp-up - Time required to set up, specific technology required such as
> a certain type of server, a Mac etc
> Skills - Required technology skills, programming languages, other skills
> to operate or deploy the tool.
> Maintenance - Resources required to maintain the tool or service
> including time and personnel, frequency of maintenance etc.
> Documentation - Is documentation available? Is it comprehensive? It is
> multi-lingual? Online or offline? Who is the target audience?
>
> Target audience - What audience can be served using this tool (age,
> demographic, region etc.)
> Reach - Projected reach of the tool. Are there external factors that
> will affect reach of this tool (geographic, language, cost, required
> partnerships?)
> Cost to end-users - If the output of this tool requires interaction by
> end-users, what are their costs? (hard costs, time required for users to
> learn interface, language, specific mobile platform etc.)
>
> Some of these factors already seem to overlap so feedback would be
> welcome. Reminder as well that this list is incredibly preliminary!
>
> Best regards,
>
> Steph
>
> http://yiibu.com
> Yiibu: Lovingly crafted mobile experiences
>
> +44 (0)7957 651 177
> Twitter: stephanierieger
>
>

-- 
Stephane Boyera		stephane@w3.org
W3C				+33 (0) 5 61 86 13 08
BP 93				fax: +33 (0) 4 92 38 78 22
F-06902 Sophia Antipolis Cedex,		
France

Received on Monday, 2 August 2010 08:45:36 UTC