List of comments on “Mobile Web Application Best Practices” (dated 13 July 2010)

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

substantive comments

Comment LC-2412: Commenter: David Campbell <dcampbell@owasp.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:
Dear Sir or Madam:

I represent the Global Industry Committee of the Open Web Application
Security Project (OWASP) and we are keenly interested in your
forthcoming Mobile Web Application Best Practices recommendation.

Attached please find a PDF document containing our comments on your
draft recommendation.

Please feel free to contact me directly with any questions, comments or
concerns.

Cheers,

David Campbell
Open Web Application Security Project
dcampbell@owasp.org
www.owasp.org; Related issues: (space separated ids); WG Notes: Notes from fd (2010-08-24): The suggested security-related additions are relevant to Web applications in general but I fail to see any mobile specificity here, so I don't think we should include any of these proposals. What we should probably do is to emphasize in the intro text of 3.2 that security measures that are valid for Web applications are de facto valid for mobile Web applications, and that we're only pointing out a best practice that has some mobile-related aspect to it in that section. Discussion and resolution at: http://www.w3.org/2010/08/24-bpwg-minutes.html#lc2412 RESOLUTION: ref. LC-2412, mark as substantive and resolve partial, pointing out that we don't have the expertise to select best practices related to security in this working group and that we focused on the most obvious one that was more particularly relevant to mobile. Future version of best practices should probably include more detailed security related best practices. Update the intro text to emphasize that most "desktop" security measures are applicable to the "mobile" context and that the best practice listed in this section is called out because of its specific mobile twist. Add wording along the lines of "example of such regular security best practices may be found at" with a reference to OWASP.; Resolution: The group partially agrees with the comment. The Mobile Web Application Best Practices is explicitly scoped to best practices that have some specific impact on the mobile context: http://www.w3.org/TR/mwabp/#mobile-context The Working Group acknowledges that most "desktop" security-related best practices also apply to mobile devices and updated the introduction text of the "Security and Privacy" section to reflect that the one best practice listed in that section is definitely not the end of it. The Working Group has also decided to reference the OWASP TOP 10 work as example of usual security measures in this text. See updated text in latest editor's draft: http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/latest#bp-security The group does not feel it has the expertise to review and select other best practices related to security and decided against adding more best practices to the section. A future version of the best practices should probably include a more comprehensive set of best practices related to security. The best practice listed in this category was chosen on the grounds that it was the most obvious client-side security hole to bridge in a mobile Web application that might have access to personal information. In particular, a mobile Widget could perhaps be allowed to send SMS or make phone calls while the device is connected to an "untrusted" public Wifi connection, thus enabling potential man-in-the-middle attacks.; (Please make sure the resolution is adapted for public consumption)

editorial comments

Comment LC-2408: Commenter: Francois Daoust <fd@w3.org> (archived message); Context: 3.4.6 Aggregate Static Images into a Single Composite Resource (Sprites); 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:
Hi,

This is a small comment on section 3.4.6 Aggregate Static Images into a Single Composite Resource (Sprites) of the second last call working draft of Mobile Web Application Best Practices:
http://www.w3.org/TR/2010/WD-mwabp-20100713/#bp-conserve-sprites

The best practice does not explicitly restrict its usage to "decorative" images. It does so implicitly through the use of examples "icons, buttons".

When applied to informative images that appear as <img> tags within the markup, this best practice would result in a mix between content and layout, since CSS then becomes mandatory to render the correct portion of the image and thus to carry the information.

I suggest to clarify the current text in the "What it means" subsection:
"Web applications often depend on a number of *decorative* images to provide icons, buttons, etc."
... instead of:
"Web applications often depend on a number of static images to provide icons, buttons, etc."

I also suggest to start the "How to do it" subsection by:
"Define candidate images as CSS background images and combine them into a single image for transfer (spriting)"
... instead of:
"Combine images into a single image for transfer (spriting)"

This has been discussed back in May 2009 from an accessibility angle, which essentially boils down to the same thing, but although there seemed to be agreement that restrictions to decorative images for this technique was a good thing, it doesn't seem to have been integrated in to the document:
http://lists.w3.org/Archives/Public/public-bpwg/2009May/0039.html
... started from Jo's question and Alan's response:
http://lists.w3.org/Archives/Public/public-bpwg/2009May/0034.html

Thanks,
Francois.; Related issues: (space separated ids); WG Notes: Notes from fd (2010-08-24): Well, of course, it's a fantastic comment ;) Discussion and resolution at: http://www.w3.org/2010/08/24-bpwg-minutes.html#lc2408 RESOLUTION: ref LC-2408 resolve as editorial and partial, add a reminder that informational image require alternative text (whereas decorative images don't); Resolution: The group partially agrees with the comment and decided to add a reminder that informational image require alternative text (whereas decorative images don't).; (Please make sure the resolution is adapted for public consumption)

Comment LC-2413: Commenter: Michael Cooper <cooper@w3.org> (archived message); Context: 3.5.2 Minimize Perceived Latency; 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 1

> 3.5.3 Design for Multiple Interaction Methods 3.5.3.1 What it means â€¦
> â€¢ Focus Based: The browser focus "jumps" from link to link;

and

> 3.5.3.2 How to do it Focus Based: â€¦
> Focus area will jump automatically from one selectable element to
> another (e.g. from link to link) without affecting usability even
> when widely spaced.

Suggest changing "from link to link" to "from element to element."; Related issues: (space separated ids); WG Notes: Notes from fd (2010-08-24): Sounds correct. I would leave the second part intact though, as selectable elements are typically links, so that's a good example of behavior. Discussion and resolution at: http://www.w3.org/2010/08/24-bpwg-minutes.html#lc2413 RESOLUTION: ref. LC-2413, mark as editorial and resolve partial. Update the text to read "The browser focus jumps from element to element". Leave the example "from link to link" in 3.5.3.2 intact though as it's a good example of mobile browser behavior.; Resolution: The group partially agrees with the comment. The text in 3.5.3.1 has been updated as suggested. However, the group decided to keep "e.g. from link to link" in 3.5.3.2 on the grounds that it is a typical example of how such mobile browsers behave on simple Web pages. See updated text in latest editor's draft: http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/latest#bp-presentation-interaction; (Please make sure the resolution is adapted for public consumption)

Comment LC-2416: Commenter: Michael Cooper <cooper@w3.org> (archived message); Context: 3.5.3 Design for Multiple Interaction Methods; 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 4

Suggest adding a fourth type of interaction method to 3.5.3.2:

Assistive Technology Based:

â€¢ Follow recommendations outlined in the Web Content Accessibility
Guidelines 2.0 [http://www.w3.org/TR/WCAG20/]
â€¢ For mobile web applications that allow creation of web content, follow
recommendations outlined in the Authoring Tool Accessibility Guidelines
2.0 [http://www.w3.org/TR/ATAG20/]
â€¢ Once the spec reaches CR, follow recommendations outlined in
Accessible Rich Internet Applications 1.0 [http://www.w3.org/TR/wai-aria/]
â€¢ Elements should be operable through means outside the primary
interaction method for each device. For example, on a device where the
primary interaction model is touch-based, assistive technology software
may operate using a focus-based interaction model even though there is
no concept of focus in the primary interaction model.; Related issues: (space separated ids); WG Notes: Notes from fd (2010-08-24): resolution follows from resolution on LC-2414. Discussion and resolution at: http://www.w3.org/2010/08/24-bpwg-minutes.html#lc2416 RESOLUTION: ref LC-2416, mark as editorial and resolve partial. Add wording along the lines of "Other guidelines and best practices are available. For instance, WCAG2.0". Do not reference ATAG as it's for authoring tools implementers and not Web developers.; Resolution: Following the resolution of Comment 2 (LC-2414), the group partially agrees with the comment and added a reference to Web Content Accessibility Guidelines 2.0 as an example of available guidelines and best practices to address other types of interaction methods. See updated text in latest editor's draft: http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/latest#bp-presentation-interaction While the Mobile Web Application Best Practices specification encourages tool developers to read the document, the main audience of the specification is Web application developers. As such, the text does not reference the Authoring Tool Accessibility Guidelines.; (Please make sure the resolution is adapted for public consumption)

Comment LC-2414: Commenter: Michael Cooper <cooper@w3.org> (archived message); Context: 3.5.3 Design for Multiple Interaction Methods; 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 2

Suggest adding a fourth type of interaction method to 3.5.3.1:

Assistive Technology Based: Events are controlled by a software
application (e.g. screen reader or voice control application) acting on behalf of the user.; Related issues: (space separated ids); WG Notes: Notes from fd (2010-08-24): Not a bad idea to include a reference to "voice" somewhere, although I don't think it qualifies as a "main interaction method". Discussion and resolution at: http://www.w3.org/2010/08/24-bpwg-minutes.html#lc2414 RESOLUTION: ref. LC-2414, mark as editorial and resolve partial. Add a reference to assistive technology and voice controlled applications as examples of other types of possible interaction methods, noting that new interaction methods are likely to emerge in the future.; Resolution: The group partially agrees with the comment. While it does not feel that a fourth type of interaction method needs to be added to the list of the main interaction methods so far, it acknowledges the importance of mentioning other types of interaction methods - including assistive technology and voice controlled applications - and updated the text consequently. The text also emphasizes that new interaction methods may emerge and become prevalent in the future. See updated text in the latest editor's draft: http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/latest#bp-presentation-interaction; (Please make sure the resolution is adapted for public consumption)

Comment LC-2415: Commenter: Michael Cooper <cooper@w3.org> (archived message); Context: 3.5.3.2 How to do it; 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 3

> 3.5.3.2 How to do it Touch Based: â€¦ Selectable elements must be large
> enough to be easily selected (e.g. list items should have a height of
> at least 30px);

Suggest using a physical size rather than a pixel size, as device
resolutions and DPI scale can vary from device to device, or explain in better detail that this is not referring to physical screen pixels.
Mobile devices today range from less than 72 dpi to greater than 300 dpi.; Related issues: (space separated ids); WG Notes: Notes from fd (2010-08-24): That's a good point. Although everyone understands what a pixel means, it does not mean much in practice on mobile phones (a CSS pixel, a real pixel?). Discussion and resolution at: http://www.w3.org/2010/08/24-bpwg-minutes.html#lc2415 RESOLUTION: ref LC-2415, mark as editorial and resolve yes. Replace 30px by physical size of a fingertip.; Resolution: The group agrees with the comment. The text was updated to mention "the physical size of a fingertip". See updated in latest editor's draft: http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/latest#bp-presentation-interaction; (Please make sure the resolution is adapted for public consumption)

Comment LC-2407: Commenter: Erik Wilde <dret@berkeley.edu> (archived message); Context: 3.5.6 Make Telephone Numbers "Click-to-Call"; 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.

http://www.w3.org/TR/2010/WD-mwabp-20100713/#bp-interaction-uri-schemes
recommends to use tel: URIs for telephone numbers. tel: is definitely
more widely known, but there also is a URI scheme for SMS, defined by
RFC 5724. mentioning it might be useful for those mobile web app authors
who like to better support SMS-based messaging in their apps.

kind regards,

erik wilde tel:+1-510-6432253 - fax:+1-510-6425814
dret@berkeley.edu - http://dret.net/netdret
UC Berkeley - School of Information (ISchool); Related issues: (space separated ids); WG Notes: Discussion and resolution at: http://www.w3.org/2010/08/24-bpwg-minutes.html#lc2407 RESOLUTION: ref LC-2407, mark as editorial and resolve yes. Mention the sms URI scheme with a link to the appropriate RFC with a warning that implementation vary very widely.; Resolution: The group agrees with the comment, and added a link to the SMS URI scheme together with a reference to RFC5724. The text includes a warning for developers about potential discrepancies in implementations at this stage. See updated text in latest editor's draft: http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/ED-mobile-bp2-20100901#bp-interaction-uri-schemes; (Please make sure the resolution is adapted for public consumption)

Add a comment.