Re: ANEC's comments on W3C mobileOK Basic Tests 1.0, W3C Working Draft 30 January 2007

 Dear Bruno von Niman ,

The Mobile Web Best Practice Working Group has reviewed the comments you
sent [1] on the Last Call Working Draft [2] of the W3C mobileOK Basic
Tests 1.0 published on 30 Jan 2007. Thank you for having taken the time to
review the document and to send us comments!

The Working Group's response to your comment is included below, and has
been implemented in the new version of the document available at:
http://www.w3.org/TR /2007/WD-mobileOK-basic10-tests-20070525/

Please review it carefully and let us know if you agree with it or not
before 22 June 2007. In case of disagreement, you are requested to provide
a specific solution for or a path to a consensus with the Working Group. If
such a consensus cannot be achieved, you will be given the opportunity to
raise a formal objection which will then be reviewed by the Director
during the transition of this document to the next stage in the W3C
Recommendation Track.

Thanks,

For the Mobile Web Best Practice Working Group,
Michael(tm) Smith
W3C Staff Contact

 1.
http://www.w3.org/mid/!&!AAAAAAAAAAAYAAAAAAAAAKev77S3u3lDobAg9fna/57CgAAAEAAAAC95k6zxtMtEj9mEnod8jQkBAAAAAA==@vonniman.com
 2. http://www.w3.org/TR/2007/WD-mobileOK-basic10-tests-20070130/


=====

Your comment on Abstract:
> Comment #1: In the perspective of the above, we believe that this may be
> understood as
> (strongly) misleading consumers, who will have other, natural
> assumptions about the
> meaning of the trust mark. Assumably, if a mobile Web site is declared
> to be “mobileOK”,
> consumers will assume the trust mark to is some kind of guarantee for
> aspects that will mean
> OK to them. In other words, it may well be assumed as a guarantee for
> reliable content, safe
> access, and trustable connections with a fair usability and some
> minimum levels of
> accessibility. Furthermore, depending on the consumer’s age,
> assumptions may even be
> made about the some kind of appropriateness of the content, when
> accessed by young
> children.
> An analogy to the above is TV sets marketed as “HD ready”. Even if
> this is only a declaration
> of one of the TV set’s capabilities, consumers (typically
> uninterested in details of this and
> other technologies) will naturally assume this to be a declaration of
> compatibility and
> capabilities for receiving and displaying high definition TV broadcasts
> without further needs to
> buy additional products (such as a set-top box) and most probably,
> subscriptions (that will
> also imply a considerable monthly fee). Consumers are often not aware
> that HD displays will
> only display an HD picture when connected to an HD receiver (set-top
> box).
> This will lead to consumer disappointment and the product may even be
> handed back. To
> continue with the analogy, “Real HD ready” TV sets are now marketed
> and the situation is
> becoming very confusing…what was “HD ready”? And what may be
> next? False marketing
> does not aid the successful uptake of new consumer technologies.
> Therefore, we suggest the re-branding of the mobileOK™ and mobileOK
> Basic™ trust marks
> in some way that reflects their true and proper meanings. Due to the
> complexity of the
> required branding, this may be a challenging task but worth the effort.
> It is not our task, nor
> competence area to propose alternative names that would work properly
> on a global market
> but wording that consumers would understand may include:
> • Ready for mobile use;
> • Mobile device adapted site;
> • This content displays OK on mobile devices.
> We believe that third party provisioning (or certification) is the only
> way to provide a reliable
> trust mark information to consumers as often, products do not match
> qualities declared by
> manufacturers, entailing a loss of consumer confidence. ANEC therefore
> encourages third-
> party certification. 


Working Group Resolution:
It is not possible to fit all of this meaning in a short brand name, and
any given name will have potential problems. That is why sections 1.1.1
and 1.1.2 explain in detail what mobileOK Pro and mobileOK Basic mean.
We'd welcome better terms, but as you say you don't have a better idea.

We have to choose something, and the names "mobileOK Basic" and "mobileOK
Pro" were selected as the most appropriate ones, as they are fairly
universal, short, and do not directly imply incorrect interpretations.
"mobileSafe" would have been a poor choice for example. "mobileOK" itself
seems to address the three points you believe consumers should
understand.

mobileOK Pro will be third-party certified. We believe that specifying
*only* third-party-certified trustmarks will severely limit adoption, to
the point that concerns about consumer understanding are moot. Hence a the
machine-verifiable "mobileOK Basic" trustmark exists.

----

Your comment on 1.1.4 Beyond mobileOK:
> Comment #2: The above is a valuable statement to developers but, again,
> misleading to
> consumers, who should understand the trust mark in the right way. 


Working Group Resolution:
We feel that enough caveats have been given earlier in the document to
cover this

----

Your comment on 2.3 Conduct of Tests:
> Comment #3: In addition to the above information recommended for
> provision, the consumer
> should be informed about the reason of failure in an understandable
> way. Additional
> information relating to other functionalities should also be provided.
> Furthermore and in
> addition, a technical reason or code may be provided to help the
> operator or creator of the
> implementation to identify the source of the error.
> Last but not least, consumers should be able to contact customer
> services through a single
> point of access per modality (e.g. by calling the “usual” number
> for all issues). 


Working Group Resolution:
mobileOK Basic Tests is not a consumer facing product. It's up to mobileOK
checkers to provide informative error messages. Where it is not clear what
the point of a FAIL is we will consider additional information

----

Your comment on 2.3.4 CSS Style:
> Comment #4: We would like the WG to confirm if the consequences of
> applying and using
> CSS have been examined with regard to mobile Web accessibility
> (possibly in collaboration
> with the WAI/WCAG Activity)? 


Working Group Resolution:
No, we believe that the work is orthogonal to WAI and have already
included new text at WAI's request to clarify that

----

Your comment on 3.3 CHARACTER_ENCODING_SUPPORT and CHARACTER_ENCODING_USE:
> Comment #5: We believe that the UTF-8 coding support should be studied
> in more detail, as
> it may have implications on the displayable text and the data
> transmission. 


Working Group Resolution:
According with the text in test
CHARACTER_ENCODING_SUPPORT/CHARACTER_ENCODING_USE "The test does not
require that resource always be encoded in UTF-8; the test merely checks
that the resource is available in UTF-8 encoding, if requested. Resources
may be delivered to devices in other encodings where appropriate. This
test verifies that a DDC-like device which only accepts UTF-8 encoding may
access the resource in UTF-8 encoding". 

----

Received on Thursday, 7 June 2007 16:12:12 UTC