[minutes] Editorial meeting on Mobile Web Application Best Practices

Hi all,

Dan, Adam, Jo_on_IRC and I had an editorial meeting on the Mobile Web 
Application Best Practices. We took a few rough notes, which are not 
exactly minutes. They are available at:
  http://www.w3.org/2009/02/10-mwabp-minutes.html

Adam should be working on an updated draft that implements some of the 
changes below.

Below is a more concrete summary of the main points raised during the 
meeting, best viewed with a copy of the latest draft on the screen:
 
http://www.w3.org/2005/MWI/BPWG/Group/Drafts/BestPractices-2.0/ED-mobile-bp2-20090101


Section 3.1 Personalization
-----
- We propose to re-focus the best practices of the section around the 
appropriate use of the local storage API for storing application data, 
when available. The current best practice deald more with regular 
session management and doesn't have any real mobile twist.
- Jo pointed out that we may need to have a specific BP around URI 
decoration and potential size limits of URIs in mobile networks. Any 
thoughts on that?


Section 3.2 Security and privacy
-----
- We reviewed the feedback from the Web Security Context Working Group:
 
http://lists.w3.org/Archives/Public/public-bpwg-comments/2009JanMar/0005.html
We recognized that there are valid use cases when storing hashed 
identities over HTTP would improve the user experience, but that the 
message would have to be so nuanced and complex that it sounds best to 
remain silent.
- We also agreed that mobile devices are more exposed to unfriendly 
networks than most desktops (e.g. public WIFI networks). We mentioned 
the idea to replace the BP by one that truly says "Use HTTPS, the 
overhead is not high once the handshake has been made". Any thought on that?
- We evaluated BPs on JSON from a mobile perspective, and realized that:
    1. there isn't any clear mobile-specific touch there
    2. since mobile devices potentially (will) give access to more APIs 
(think geolocation, calendar, contacts list, ...), there's even a higher 
risk to have malicious code executed on mobile devices.
We thus recommend to drop 3.2.2 and to switch 3.2.3 to something along 
the lines of "do not use eval to run untrusted Javascript feeds"


Section 3.3 User awareness and control
-----
We mostly skipped the section. Several comments need to be taken into 
account, but the section looks fine otherwise.


Section 3.4 Conservative user of resources
-----
- We agreed with Jo's former comment that 3.4.1.3 goes too much into 
detail for no clear benefit and should be removed.
- We discussed push methods in 3.4.5. Jo and I raised the fact that the 
BP cannot be actioned by anyone. We agreed to reword the BP in a more 
"network provider" centric way and to get back to the group with the 
updated wording. Jo raises the fact that WiFi only mobile devices de 
facto require a different approach.


Section 3.7 SVG
-----
- The section is mostly void for the time being, i.e. does not say much 
apart from "use SVG because it's cool". Any real BP we could think of 
and put in this section? "Use SVG so that images automatically scale to 
fit the width of the screen"?


Best practices flags
-----
Following one of the last discussions of the mailing-list, we thought 
that it would be useful for readers to identify BPs that matter to them 
easily. Defining precise required capabilities for each BP is likely to 
result in a dead end and would probably not help readers anyway.

The idea we propose is to use a set of simple icons to flag best 
practices. The flags would not need to carry a specific set of device 
capabilities. The list could be:
  ALL: the BP applies to most devices
  CSS: the BP requires the device to have a good support of CSS
  XHR: the BP requires the device to support AJAX-like requests and 
scripting
  SCRIPT: the BP requires the device to support scripting, although not 
necessarily the XHR object (could be merged with former one)
  HTML5: the BP requires some support of advanced HTML5 features 
(typically local-storage)
  SVG: provided we end up with SVG best practices.

I ran through the list of Best practices. I see a couple of them that do 
not quite match any of the categories but could probably be flagged as 
ALL anyway. What about it?


Francois.

Received on Friday, 13 February 2009 15:26:51 UTC