Final comments on the roadmap document

Dear all,
    Re-listing here some of the comments from my previous mail dated sep
21st :

http://lists.w3.org/Archives/Public/public-mw4d/2009Sep/0009.html

and some additional comments on the remaining sections .....

 Comments on the structure of the document,
    a. abstracts shouldn't include section numbers.
    b.   exec summary should always be placed before the
introduction because the section  literally means for the execs or those who
require a snapshot of the essence of the document without sifting through
the individual chapters.....
    c. Scope of the document should be placed before the "challenges"
section since the scope draws the boundaries for the audience before we get
to the subject matter. Correspondingly, some of the scope related comments
written in various sections (mostly as NB) should be incorporated in to the
scope section.
   d. I had indicated the creation of a separate section for definitions and
also the candidates for this section (
http://lists.w3.org/Archives/Public/public-mw4d/2009Sep/0009.html )
   e. There should be a consistency in the usage of the term representing
"mobile for social development" across the document... somewhere we have
used mobile for ICT development, somewhere MW4D, and so on... may be we can
decide on a single term that represents this for the sake of consistency...
   f. For both the tables in exec summary, care should be taken that the
colours chosen are reader-friendly when print out is taken in black and
white...
  g. Considering that the document will be read by many as printed copies, I
think we should place the reference links explicitly in the reference
section as opposed to being embedded as is the case now.....
  h. In the Audience section, I felt that Donor's role is similar to that of
R&D Organizations/Foundations etc...hence added Donors to that role... also
reordered the existing audience list to start with the
practitioners/developers and then to those who use these applications....

Comments on the content of the text:

In Table 1 (Exec summary section):

Regarding the column discussing the cost of service......

"Value" is a loaded term which means the value perceived or received by the
end-user for a service... and this is different from the "cost" which the
price of the service.... End-users may find some services of higher value
than the cost or vice versa... In short, cost and value do not mean the same
and what we are probably trying to say here is about the cost and not
value... so we should replace cost with Tariff (in the first row) and then
replace value with cost (in the second row)... so that we mean Tariff
predictability and Tariff cost.

In section  6.1.3:

Regarding the statement on lesser-known languages......

I think we need to be explicit on what we mean by lesser-known languages...
Perhaps explictly mention that these are languages lesser-known (though may
not be less spoken) to the majority of the developer communities active on
the ICT domain.

In section 6.1.4:

Regarding Portals vs. Mobile widgets....

I am unsure as to whether we can suggest Portals as always closed and mobile
widgets as always open.... Is it unrealistic to consider portals with mobile
widgets? This is perhaps related to the whole debate/hype of app stores but
I see it more as a business model shift.... At the end of the day are app
stores also not some kind of portals?

In section 6.1.5:

Regarding statement on billing support for USSD .....

USSD enabled services can be charged though USSD per se cannot .....

In section 6.2.4:

Regarding costs for service providers.....

Why is there no cost of delivery for data services as suggested in the
document?

Regarding voice and SMS, it's not always based on who initiates the
call. Reverse billing is also possible in the cases where the service
provider incurs all the cost....Correspondingly in "service delivery model"
section, the statement suggesting SMS services cannot be offered free unless
through broadcast should be changed.

In section 6.2.5:

Regarding discoverability in the case of SMS and voice, the document points
towards the lack of an in-built function for search.... I believe that the
underlying bearer service never will have this in-built.. and this is true
also for data services.... web-based search is an application which enables
search and not the data bearer per se which has this functionality....

Finally, in section 9:

I think the issue of developing standard interfaces for integrating SMS &
Voice to Web will be critical (as more and more information is updated and
added to the web) and therefore needs to be highlighted (perhaps in the R&D
actions)

Hopefully, I have covered most of my comments.....and perhaps it's not too
late to consider these....

Overall, the document indeed has come out good and hopefully will serve its
purpose pretty well....

Thanks to Stephan and all for this effort!

Regards
Renjish