List of comments on “Mobile Web Best Practices 1.0” (dated 13 January 2006)

Quick access to

There are 171 comments (sorted by their types, and the section they are about).

1-20 21-40 41-60 61-80 81-100 101-120 121-140 141-160 161-171

substantive comments

Comment LC-264: Commenter: Ian Jacobs <ij@w3.org> (archived message); Context: Document as a whole; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
The terms "easily" and "efficiently" are almost unused in the document. In my opinion that do not add much information where they are used and might be safely deleted from this part of the document and from the best practices below.

I suspect this entire section could be reduced without significant loss of information to the following:

The quality of the user's Web experience via a mobile device depends significantly on the usability of Web sites, of browsers, and of the device itself. Although browser usability (for reading, navigating, and interacting with content) and device usability are important, this document focuses primarily on best practices for improving site usability.; Related issues: (space separated ids); WG Notes:; Resolution: We agree and we have integrated your suggested rewrite in the section on Phasing, having removed the section on usability as such.; (Please make sure the resolution is adapted for public consumption)

Comment LC-374: Commenter: Bruno von Niman (ANEC W3C) <ANEC_W3CRep_Bruno@vonniman.com> on behalf of ANEC (archived message); Context: Document as a whole; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
Chapter 1.3.3, One Web: With the currently available technologies and implementations
(and considering the product generation gaps), it is not always desirable, beneficial nor
affordable to consumers to access the same information, provided on the same format,
regardless of the access network and device.
Although technology will improve continuously, consumer requirements will be strongly
influenced by the context of mobile use (on the move, limited screen and keyboard,
disturbing environment, et cetera), will not change that radically.
Due to the context of mobile use, terminal capability variations, bandwidth issues, access
rights and mobile network capabilities, this principle should be reconsidered.
Even if it is easier to develop content for one Web, there are specific issues that need to be
addressed.
Providing a good and affordable mobile Web user experience becomes even more important
to roaming consumers (presently, there is no low-cost global roaming tariff plan for mobile
data devices).
We would like to discuss the approach taken and would appreciate to hear your arguments
for the â€œOne Webâ€? approach taken.; Related issues: (space separated ids); WG Notes:; Resolution: We already address these issues, but we have slightly revised part of the One Web definition to be more explicit and use the word "representation" (as defined in the DI glossary) in the following text: "As discussed in [Scope] One Web means making, as far as is reasonable, the same information and services available to users irrespective of the device they are using. However it does not mean that exactly the same information is available in exactly the same representations across all devices. This is due to issues such as the context of mobile use, terminal capability variations, bandwidth issues and mobile network capabilities. Furthermore, some services and information are more suitable for and targeted at particular user contexts." We have also added a link to the Thematic Consistency Best Practice, which give more context on this point.; (Please make sure the resolution is adapted for public consumption)

Comment LC-375: Commenter: Bruno von Niman (ANEC W3C) <ANEC_W3CRep_Bruno@vonniman.com> on behalf of ANEC (archived message); Context: Document as a whole; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
Chapter 1.4, Default Delivery Context: More detailed specifications should be provided. In
addition, possible fall-back solutions should be mentioned.; Related issues: (space separated ids); WG Notes:; Resolution: We have added links to the details of the specifications referenced in the default delivery context. The fall-back solutions belongs in the techniques document.; (Please make sure the resolution is adapted for public consumption)

Comment LC-436: Commenter: <fsasaki@w3.org> on behalf of I18N WG (archived message); Context: in; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
Comment from the i18n review of:
http://www.w3.org/TR/2006/WD-mobile-bp-20060113/

Comment 21
At http://www.w3.org/International/reviews/0602-mwbp10/
Editorial/substantive: S
Owner: RI
Location in reviewed document:
General

Comment:

We believe the document should encourage all participants in the mobile value chain to support Unicode. This is extremely helpful in ensuring international use of this technology and ease of localization of content.; Related issues: (space separated ids); WG Notes: richard reply about their disagreement: """ The current text, however, doesn't particularly encourage content authors to use UTF-8. On the contrary, since it talks about using the value of the Accept-Charset header and is noncommittal about which encoding is being indicated using the Content-Type header and what determines the choice of encoding, it makes no clear recommendation to use utf-8. I think it would be useful to draw on what you say in your response below so that the last paragraph says what you are thinking, eg.: "All applications should support UTF-8. As the default delivery context assumes only UTF-8 support, this means that by default, content providers should serve content UTF-8 encoded (unless they know that the targeted device doesn't support it)." If we can get people used to using utf-8, and away from legacy encodings, we can make a big improvement to the multilingual Web, but content authors need to hear that message as well as application authors. """; Resolution: After futher discussion with Richard Ishida, we have added more specific recommendations as to why using Unicode is a smart thing to do: "Encoding of the content to a desired character encoding is dependent on the authoring tools being used, Web server configuration and the server side scripting technology being used (if any). For a discussion of this see [CHARSET1] and [CHARSET2]. Unicode is a good choice for representing content when served in multiple languages. The amount of bandwidth required to transmit content can vary significantly depending on the character encoding used. Text consisting principally of characters from the Latin alphabet will encode more efficiently in UTF-8, whereas text consisting principally of characters from ideographic scripts will encode more efficiently in UTF-16. When choosing a character encoding, consider the efficiency of the available encodings. Since the Default Delivery Context specifies use only of UTF-8, all applications should support UTF-8. "; (Please make sure the resolution is adapted for public consumption)

Comment LC-366: Commenter: Bruno von Niman (ANEC W3C) <ANEC_W3CRep_Bruno@vonniman.com> on behalf of ANEC (archived message); Context: Document as a whole; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
We believe that Web site access through mobile devices would benefit from the
provision of some minimum-level requirements on terminal capabilities and browser
features. If this cannot be achieved, other work should be referenced.; Related issues: (space separated ids); WG Notes:; Resolution: The Default Delivery Context (section 1.4 in the Last Call Working Draft) provides the assumed minimum-level requirements alluded to.; (Please make sure the resolution is adapted for public consumption)

Comment LC-391: stricter scrolling limits: Commenter: <Jyri.Hagman@nokia.com> on behalf of Nokia (archived message); Context: Document as a whole; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
5.3.3 Scrolling
There could be a stricter recommendation: Limit scrolling
while reading a single text flow to one direction.; Related issues: (space separated ids); WG Notes:; Resolution: We have simplified the pair of Best Practices on scrolling into a single best practice, recommending not allow secondary scrolling unless necessary.; (Please make sure the resolution is adapted for public consumption)

Comment LC-367: Commenter: Bruno von Niman (ANEC W3C) <ANEC_W3CRep_Bruno@vonniman.com> on behalf of ANEC (archived message); Context: Document as a whole; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
Accessibility should be addressed more specifically, as the mobile Web (and its
specific issues) does not seem to be in the scope of the WAI/WCAG guidelines 2.0,
currently under updating. The provided cross-referencing is beneficial but it does not
provide enough substance.; Related issues: (space separated ids); WG Notes:; Resolution: The group took inspiration from WCAG 1.0 (and links back to it), but the accessibility experts are in the WAI groups. As such, we think further work on accessibility in the mobile context is out of our scope.; (Please make sure the resolution is adapted for public consumption)

Comment LC-368: Commenter: Bruno von Niman (ANEC W3C) <ANEC_W3CRep_Bruno@vonniman.com> on behalf of ANEC (archived message); Context: Document as a whole; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
Access to the mobile Web through a speech user interface is not covered by the
present draft version. We believe it should be addressed (also as there is excellent
work in W3C to cross-reference), as it is an important accessibility enabler to young
and older users and users with temporary or permanent functional abilities.; Related issues: (space separated ids); WG Notes:; Resolution: This is out of scope of the current phase of work of the Best Practices, as stated in our scope document: """ As the Mobile Web Initiative is primarily concerned with accessing content that would currently be rendered in a desktop or laptop browser, the BPWG's focus is currently on best practices that are most pertinent to "traditional" browsing. However, in future phases, the group may broaden the scope of its work in order to take into account other content presentation options that may be available on mobile devices - e.g., using the emerging multimodal technologies.""" http://www.w3.org/TR/2005/NOTE-mobile-bp-scope-20051220/#s2; (Please make sure the resolution is adapted for public consumption)

Comment LC-346: Commenter: Ville Karinen <ville.karinen@helsinki.fi> (archived message); Context: Document as a whole; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
Hello all,

i remember there was some discussion whether MWBP promotes One Web or
not, but in any case, i guess one goal of the *document* is to explain
different kind of approaches or strategies how Web can be served
for/accessed via mobile device.

"The primary goal is to improve the user experience of the Web when
accessed from such devices."

However, it seems that the document is concentrating mainly on authoring
process. As we can change the existing Web very slowly, it would be
informative for non-mobile Web experts to illustrate already existing
Web to Mobile adaptation processes, which are based on proxy based
conversion. These conversion proxies provide the most widest Web to
Mobile resource today.

Here are some examples which kind of proxies i mean:

WEB TO MOBILE

Google's quite new HTML -> XHTML MP converter:
<http://www.google.com/gwt/n?&u=www.w3.org/TR/2006/WD-mobile-bp-20060113/>
MWBP document (WAI) conversion as an example. This converter can handle
even forms.

<http://mini.opera.com> (Opera Software MIDP browser based on proxy
adaptation. This combination enhances site and browser usability)

HTML-> WML conversion
<http://wap.google.com>
<http://maddingue.free.fr/softwares/html2wml.html> (handles forms also)

Maybe it should explained more clearly, why WAI guidelines - for example
- do not cater mobile devices enough. In my opinion, different kind of
Web to Mobile proxies should be studied in the future working groups -
especially with content conforming relevant (and existing) WAI guidelines.

It is said, that the mobile handset can be the only Web device for many
users in the third world. That is why it is important to note, that
conversion proxies might be someties the only way to get information
from the Web.

Kind Regards,
Mr. Ville Karinen
Student (Agr. & For.); Related issues: (space separated ids); WG Notes:; Resolution: As stated in the "Classes of products" section [2], we're only dealing with "content as it gets delivered to a Web user agent". The way it is authored, adapted or proxied along the delivery chain is thus out of scope for our document, although we briefly explain where content adaptation fits in there [3]. Furthermore, a W3C Technical Report would not be the right place to present vendor-specific solutions for content adaptation. Nevertheless, the Techniques the Working Group has started to work on will present a set of technical advices regarding how to put the best practices in application; as these techniques will be open for contributions, maybe could you then suggest something along the lines of your email message? In the meantime, is there a way to rephrase your comment in a way that would fit in the scope of our best practices? Thank you very much for the time you took to review and comment on the document. Dom 1. http://www.w3.org/TR/2006/WD-mobile-bp-20060113/#iddiv3102433376 2. http://www.w3.org/TR/2006/WD-mobile-bp-20060113/#iddiv2102690416 3. http://www.w3.org/TR/2006/WD-mobile-bp-20060113/#iddiv2102182960; (Please make sure the resolution is adapted for public consumption)

Comment LC-370: Commenter: Bruno von Niman (ANEC W3C) <ANEC_W3CRep_Bruno@vonniman.com> on behalf of ANEC (archived message); Context: Document as a whole; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
Setup and configuration is currently considered by consumers as a major difficulty,
when trying to access mobile services and applications. As this document does not
address setup and configuration-specific issues and it does not provide such
guidelines, it should reference available recommendations and best practices
developed in other standard bodies and fora, in order to improve the user experience.; Related issues: (space separated ids); WG Notes:; Resolution: Setup and configuration is out of scope for the Mobile Web Best Practices which only focus on the delivery of content to Mobile Web devices.; (Please make sure the resolution is adapted for public consumption)

Comment LC-267: Commenter: Ian Jacobs <ij@w3.org> (archived message); Context: 1.3.3 One Web; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
"From the perspective of this document this means that services should be available as some variant of HTML over HTTP."

Why is the previous statement here? It sounds like it is an assumption about delivery and belongs in the next section.; Related issues: (space separated ids); WG Notes:; Resolution: Yes and no: yes, HTTP has been added in the default delivery context -- but no, it also belongs here -- as a clarification of what "One Web" means in the context of this document.; (Please make sure the resolution is adapted for public consumption)

Comment LC-358: Commenter: Charles McCathieNevile <chaals@opera.com> on behalf of Opera Software (archived message); Context: 1.4 Default Delivery Context; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
3. Security

In order to build commercial services on the web, secure connections are
necessary. In addition, these are widely implemented already. Is there no
requirement to support https connections in the mobile space as a best
practice?; Related issues: (space separated ids); WG Notes:; Resolution: We don't have any best practice regarding security, and deploying a secure service on the Web and on mobile devices require much more guidance than simple best practices. As a consequence, the group doesn't feel the document should talk about HTTPS.; (Please make sure the resolution is adapted for public consumption)

Comment LC-359: Commenter: Charles McCathieNevile <chaals@opera.com> on behalf of Opera Software (archived message); Context: 1.4 Default Delivery Context; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
4. HTTP

It is not clear that any transport protocol is guaranteed on the device.
Given the requirements to support the regular web, and in particular such
things as 30x HTTP responses, it would be appropriate to specify a level
of HTTP support in the default characteristics. mobile space as a best
practice?; Related issues: (space separated ids); WG Notes:; Resolution: We do say in 1.3 "From the perspective of this document this means that services should be available as some variant of HTML over HTTP." but indeed HTTP wasn't part of the default delivery context. We have added HTTP 1.0 as part of the default delivery context.; (Please make sure the resolution is adapted for public consumption)

Comment LC-360: Commenter: Charles McCathieNevile <chaals@opera.com> on behalf of Opera Software (archived message); Context: 1.4 Default Delivery Context; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
5. Style sheets

XHTML Basic does not include any support for internal styles. It makes
sense, given the problems of latency that are a key constraint in the
mobile space, to mandate support for internal styling, but it is not clear
from the current wording what support can be expected (and therefore, as
an implementor, what support we are implicitly being required to provide).; Related issues: (space separated ids); WG Notes:; Resolution: We have clarified the default delivery context, and now it only allows external style sheet as required by XHTML Basic.; (Please make sure the resolution is adapted for public consumption)

Comment LC-398: Commenter: Zev Blut <zb@ubit.com> (archived message); Context: 1.4 Default Delivery Context; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
1.4 Default Delivery Context
There is an entry for screen width, but not height. I think that there
should be some value for a default screen height.; Related issues: (space separated ids); WG Notes:; Resolution: We decided not to include the screen height because: * research showed that even being able to view only a few lines (4) was sufficient for a reasonable user experience * we didn't want to fix the aspect ratio; (Please make sure the resolution is adapted for public consumption)

Comment LC-357: Commenter: Charles McCathieNevile <chaals@opera.com> on behalf of Opera Software (archived message); Context: 1.4 Default Delivery Context; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
2. Colours:

There are a number of interpretations of "websafe" colours - please
provide a reference that unambiguously states which colours are expected
to be available.; Related issues: (space separated ids); WG Notes:; Resolution: We have added the definition that a Web safe color as one which has Red/Green/Blue components chosen only from the values 0, 51, 102, 153, 204, and 255.; (Please make sure the resolution is adapted for public consumption)

Comment LC-421: Commenter: <fsasaki@w3.org> on behalf of I18N WG (archived message); Context: 2.2 Input; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
Comment from the i18n review of:
http://www.w3.org/TR/2006/WD-mobile-bp-20060113/

Comment 6
At http://www.w3.org/International/reviews/0602-mwbp10/
Editorial/substantive: S
Owner: FS
Location in reviewed document:
Sec. 2.2 [http://www.w3.org/TR/2006/WD-mobile-bp-20060113/#iddiv2102172624]

Comment:

We propose to add to this section on \"input\" the requirement to provide an adequate input method for the user. Especially for complex scripts like Chinese or Japanese, this is a crucial requirement.; Related issues: (space separated ids); WG Notes:; Resolution: The Best Practices do not set requirements on user agents, only on content; we already give recommendations on input mode for the content (see AVOID_FREE_TEXT and DEFAULT_INPUT_MODE]. Any further consideration would better fit in the techniques related to these best practices, on which we welcome contributions: http://www.w3.org/2005/MWI/BPWG/techs/CategoryBpDefaultInputMode http://www.w3.org/2005/MWI/BPWG/techs/CategoryBpAvoidFreeText; (Please make sure the resolution is adapted for public consumption)

Comment LC-399: Commenter: Zev Blut <zb@ubit.com> (archived message); Context: 2.2 Input; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
2.2 Input
Discusses the potential lack of back button support, but in section 1.4
the default device supports XHTML- Basic. Is it not reasonable that if
the default is assuming XHTML-Basic then the target default handsets
have back buttons?; Related issues: (space separated ids); WG Notes:; Resolution: The "back button" is not mandated by any of the specifications that defines the default delivery context, and in particular, there doesn't seem to be any evidence that any device supporting XHTML-basic would feature a back button. As such, we have kept our text regarding the back button as is.; (Please make sure the resolution is adapted for public consumption)

Comment LC-422: Commenter: <fsasaki@w3.org> on behalf of I18N WG (archived message); Context: 2.3 Bandwidth and Cost; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
Comment from the i18n review of:
http://www.w3.org/TR/2006/WD-mobile-bp-20060113/

Comment 7
At http://www.w3.org/International/reviews/0602-mwbp10/
Editorial/substantive: E
Owner: FS
Location in reviewed document:
Sec.2.3 [http://www.w3.org/TR/2006/WD-mobile-bp-20060113/#iddiv2102173616]

Comment:

In some character encodings like UTF-8, scripts with a similar number of characters (e.g. latin versus indic scripts) vary in space requirements. To avoid high bandwidth / cost related to scripts, you might propose for such cases the use of the
compression scheme for unicode [http://www.unicode.org/reports/tr6/]
.; Related issues: (space separated ids); WG Notes:; Resolution: We have not found sufficient support for this encoding scheme in mobile devices.; (Please make sure the resolution is adapted for public consumption)

Comment LC-277: Commenter: Ian Jacobs <ij@w3.org> (archived message); Context: 2.7 Advantages; Status:
Not assigned; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
"As an illustration of some of these factors: First, unlike the fixed Web, the mobile Web will go where you go. No longer will you have to remember to do something on the Web when you get back to your computer. You can do it immediately, within the context that made you want to use the Web in the first place."

The previous paragraph needs to be adjusted. The text (which may have come initially from the Communications Team!) suggests that there are two Webs: one fixed and one mobile. That is not a message we want to communicate. The point is that we want one Web and that we want to improve mobile access to it.; Related issues: (space separated ids); WG Notes:; Resolution: We have changed the term to "Mobile Web access" to clarify that it's not the mobile web but mobile access to the Web.; (Please make sure the resolution is adapted for public consumption)

1-20 21-40 41-60 61-80 81-100 101-120 121-140 141-160 161-171

Add a comment.